Issue with init and shutdown ( Caused by: java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE => [])

[olamy]

Sorry to write here but I cannot find a place to create an issue.
While working on integrating weld 6.0.1 with arquillian-container-jetty for Jettty 12.1 (ee11).
I'm facing an issue (see PR arquillian/arquillian-container-jetty#238).

The ServletContainerInitializer org.jboss.weld.environment.servlet.EnhancedListener is registered but eventually there is no beans.xml or no beans with annotations so the Weld runtime is not setup and the message:

WARN: WELD-ENV-000028: Weld initialization skipped - no bean archive found

Now at shutdown, the shutdown is generating an error and so failing proper shutdown.

Caused by: java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE => []
	at org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:31)
	at org.jboss.weld.Container.instance(Container.java:65)
	at org.jboss.weld.bootstrap.WeldRuntime.shutdown(WeldRuntime.java:81)
	at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:115)
	at org.jboss.weld.environment.servlet.WeldServletLifecycle.lambda$initialize$1(WeldServletLifecycle.java:238)
	at org.jboss.weld.environment.servlet.WeldServletLifecycle.destroy(WeldServletLifecycle.java:247)
	at org.jboss.weld.environment.servlet.EnhancedListener.contextDestroyed(EnhancedListener.java:90)
	at org.eclipse.jetty.ee11.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:1625)

Is there any workaround for this?
Or are you happy to consider this as a bug?
Thanks

[manovotn]

Sorry to write here but I cannot find a place to create an issue.

That's perfectly fine.
FTR, issues are still tracked in JIRA - https://issues.redhat.com/projects/WELD

WARN: WELD-ENV-000028: Weld initialization skipped - no bean archive found

So this I recall was deliberate to avoid booting Weld in scenarios when there were no beans. However, the exception is weird.
Note that in case Weld doesn't perform init, it shouldn't do shutdown either (the shutdownAction in WeldServletLifecycle won't be set) so I don't think this is the cause of your problems.

I checked out the branch from your PR and weirdly enough the failure only occurs on running all tests. Running any in particular doesn't show it.

With some debugging I can see that:

• For the whole testsuite Weld is being initialized 4 times, two of which are skipped (no bean archive)
  • Initialization happens through EnhancedListener#onStartup
  • I assume the skips are the Arq. deployment JARs which would be expected
• There is no shutdown until all tests are over and then several are done subsequently
  • Shutdown is done through EnhancedListener#contextDestroyed
  • This is IMO what causes issues as both containers are defines with identical (default) IDs hence the second one attempts to destroy an already inactive container

I don't know how Jetty Arq. container works but this setup seems wrong - I would expect whole init and tear down per test class @olamy ?

Also, was this an issue in earlier versions? I am not aware of Weld 5 -> 6 change that would cause this.

EDIT: I should add that the default ID is the "STATIC_INSTANCE" you are seeing - a shared Weld instance. Though I am not sure you can avoid shutting it multiple time in case of servlet simply because it is bound to the contextDestroyed event 🤔

[olamy]

@manovotn Thanks for your quick answer

This is IMO what causes issues as both containers are defines with identical (default) IDs hence the second one attempts to destroy an already inactive container

good point. using different id such webapp context might be a solution

I don't know how Jetty Arq. container works but this setup seems wrong - I would expect whole init and tear down per test class @olamy ?

Actually it's general Arquillian, the container is started only once then app are deployed/undeployed

Also, was this an issue in earlier versions? I am not aware of Weld 5 -> 6 change that would cause this.

I need to check something as we changed our Jetty deployment 12 -> 12.1

I will dig a bit more.
Thanks for your helpful answers.

[olamy]

great this change definitely fixed my issue: arquillian/arquillian-container-jetty@88ed73b#diff-6171d6014ad7e76c9521da4469790ab0f824b140cd37e6ddece4984853cb819cR255

I'm still not sure why it worked with Jetty 12.0.x though

[manovotn]

good point. using different id such webapp context might be a solution
Actually it's general Arquillian, the container is started only once then app are deployed/undeployed

It still sounds more like a workaround - I'd expect the deploy/undeploy to happen per test class and trigger Weld startup/shutdown.
I no longer recall the details of Arq. but imagine having a big test set; in such case you'd quickly run out of resources as you keep booting new containers but don't shutdown until you run all tests?

I'm still not sure why it worked with Jetty 12.0.x though

@olamy I did a quick test debug for arquillian-container-jetty/jetty-embedded-12-ee10 and it behaves just as I described above - each test class does its deploy/undeploy before running another and that starts and stops Weld properly. So something in the deployment changes from your commit seems to break that.

[manovotn]

Closing as outdated as there was no further communication; feel free to reopen if you feel like there is more to be discussed.

Just FTR, I would consider the jetty-embedded-12-ee10 behavior we discussed earlier to be a bug on the adapter side.