[GLASSFISH-18435] IllegalStateException: Singleton not set for ... when invoking @PreDestroy on @SessionScoped bean Created: 01/Mar/12  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: titmus Assignee: jwells
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log     Zip Archive tests-session-bean.zip    
Tags: 4_0-approved

 Description   

I had an issue with @SessionScoped beans giving me an error during execution of @PreDestroy method.
In the server.log there were lines similar to this
[#|2012-03-01T09:16:14.799+0100|SEVERE|glassfish3.1.1|org.jboss.weld.Bean|_ThreadID=23;_ThreadName=Thread-2;|WELD-000019 Error destroying an instance Managed Bean [class test.SessionBeanProducer] with qualifiers [@Any @Default] of test.SessionBeanProducer@1c65470|#]

I investigated it a little bit and found thad when @PreDestroy method invoked @RequestScoped bean, the method org.glassfish.weld.ACLSingletonProvider.ACLSingleton#get raised IllegalStateException.
When this method was invoked TCCL was set to WebApp classloader but in the store only ear class loader was registered

The issue seems to be specific to EAR deployments. I created an arquillian test case demonstrating the issue.



 Comments   
Comment by titmus [ 01/Mar/12 ]

The expected behaviour would be that ContextNotActiveException is raised, but in the actual application I have a request context active during @PreDestroy annotated method invocation.

In my application classloader hierarchy for TCCL when org.glassfish.weld.ACLSingletonProvider.ACLSingleton#get is called is as follows:

org.glassfish.web.loader.WebappClassLoader
org.glassfish.internal.api.DelegatingClassLoader
java.net.URLClassLoader
com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader
sun.misc.Launcher$ExtClassLoader

There is no EarLibClassLoader in the classloader hierarchy.

Comment by Sivakumar Thyagarajan [ 10/Dec/12 ]

Transferring to JJ Snyder

Comment by edilmar [ 08/Feb/13 ]

I have the same problem with GF3.1.1 + JSF2 + Weld + CODI.
I use Conversation class from CODI, not Weld, and when I change from a Controller to other, after call conversation.close(), it appears the message "SEVERE: WELD-000019 Error destroying an instance Managed Bean" between any Controller changing.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

John
Can you eval this issue for inclusion into or exclusion from 4.0 ?

Comment by jwells [ 26/Apr/13 ]

This is the exception that is thrown in 4.0. I think this is the correct exception to be thrown here, but have some doubts I'm trying to resolve...

org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:667)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:74)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at com.oracle.cdi.cases.devtests.predestroy.lib.RequestBean$Proxy$_$$_WeldClientProxy.beanMethod(Unknown Source)
at com.oracle.cdi.cases.devtests.predestroy.war.SessionBeanProducer.destroy(SessionBeanProducer.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:89)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:82)
at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:99)
at org.jboss.weld.injection.producer.BeanInjectionTarget.preDestroy(BeanInjectionTarget.java:73)
at org.jboss.weld.bean.ManagedBean.destroy(ManagedBean.java:186)
at org.jboss.weld.context.ForwardingContextual.destroy(ForwardingContextual.java:31)
at org.jboss.weld.context.AbstractContext.destroyContextualInstance(AbstractContext.java:150)
at org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:163)
at org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:41)
at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:157)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:5261)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:255)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:359)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)]]

Comment by jwells [ 26/Apr/13 ]

I believe the assumption in the code is that session.invalidate causes the session scope to be destroyed right then and there (leaving the request scope active, but the session scope destroyed). However (as can be seen from the above stack) this is not exactly correct, as the session scope is not truly removed until the request is over. This seems correct to me, so I think this is now working properly.

I would like to add a test case that verifies that this case throws ContextNotActive rather than IllegalState to make sure this does not regress again.

Comment by jwells [ 26/Apr/13 ]

What is the impact on the customer of the bug?

None. This bug has been fixed. However, I now have a specific test case for it I would like to check in so it never regresses.

What is the cost/risk of fixing the bug?

There is no risk, I would like to check my test case in (which lives under appserver/tests and is run by this hudson: http://hudson-sca.us.oracle.com/job/gf-cdi/)

Is there an impact on documentation or message strings?

No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

CDI hudson

Which is the targeted build of 4.0 for this fix?

b88

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

n/a

Comment by jwells [ 26/Apr/13 ]

Test case added with 61666

Generated at Mon Jan 16 10:45:43 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.