Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deployment to Payara fails due to lifecycle failure in DefaultWatchThread #756

Open
jcosmo opened this issue Jul 15, 2024 · 3 comments
Open

Comments

@jcosmo
Copy link

jcosmo commented Jul 15, 2024

Expected Behavior

Create a relatively simple app from micronaut launch.
Add micronaut-servlet.
Package as a war.
Deploy to payara.

Deployment should have worked

Actual Behaviour

Deployment fails with the error:
The return type of the lifecycle method [start] must be void. Related annotation information: annotation [@javax.annotation.PostConstruct()] on annotated element [public io.micronaut.scheduling.io.watch.DefaultWatchThread io.micronaut.scheduling.io.watch.DefaultWatchThread.start()] of type [METHOD]

Steps To Reproduce

Via micronaut launch, take a vanilla application, java 17, groovy.

add to build.gradle:
developmentOnly("io.micronaut.servlet:micronaut-http-server-tomcat:4.9.2")
implementation("io.micronaut.servlet:micronaut-servlet-engine:4.9.2")
plugins: id "war"

build war, deploy to payara

Environment Information

JDK 17
Ubuntu linux
Payara 5.2022.5, or Payara 6.2024.6 (latest)

Example Application

demo.zip

Version

4.4.0

@jcosmo jcosmo changed the title Deployment to Payara fails due to lifecycle failure in Deployment to Payara fails due to lifecycle failure in DefaultWatchThread Jul 15, 2024
@graemerocher
Copy link
Contributor

I believe you have to disable annotation scanning on the server

@graemerocher
Copy link
Contributor

@jcosmo
Copy link
Author

jcosmo commented Jul 15, 2024

I was aware of the need to disable CDI scanning, and have done so. Sorry, should have made that clearer in the instructions.
image

Though, maybe, the value in the deployment descriptor in the war is overriding the console. I shall check.

Result of checking:

  • It's a war, not an ear, so no deployment descriptor.
  • The console value wins in all cases unless the deployment descriptor forces the value to true.
  • Thus I believe I've correctly attempted to deploy with Implicit CDI disabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants