<font size=2 face="sans-serif">Thanks Martin, this is useful context<br>
<br>
Regards<br>
Benjamin</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Martin Kouba <mkouba@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Benjamin Confino <BENJAMIC@uk.ibm.com>,
Matej Novotny <manovotn@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">weld-dev@lists.jboss.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">14/06/2018 10:28</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [weld-dev]
RquestScoped not active inside WeldInitialListener.requestDestroyed</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hello Benjamin,<br>
<br>
First of all, there is no guarantee that the request context is active
<br>
during @PreDestroy of a @SessionScoped bean (unlike @PostConstruct <br>
callback of any bean). And it is certainly not active when an http <br>
session times out. And that's the reason why <br>
UserSessionData.preDestroy(), which invokes @RequestScoped MyPrincipal
<br>
created by PrincipalProducer.produce(), is not correct.<br>
<br>
In this particular case, Weld follows the spec and destroys the session
<br>
context "at the very end of the request in which invalidate() was
<br>
called" [1]. So it's not destroyed immediately when invalidate() is
<br>
called. Furthermore, the order in which HTTP contexts are destroyed is
<br>
not defined. If needed, Weld first destroys conversation, then request
<br>
and finally session context. That's why the customer gets <br>
ContextNotActiveException.<br>
<br>
It's more like a chicken-egg problem. And since the session context has
<br>
"wider" scope I think it makes more sense to allow @RequestScoped
beans <br>
to access the session context in @PreDestroy callbacks and not vice versa.<br>
<br>
Martin<br>
<br>
[1]<br>
</font></tt><a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#session_context_ee"><tt><font size=2>http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#session_context_ee</font></tt></a><tt><font size=2><br>
<br>
Dne 13.6.2018 v 16:23 Benjamin Confino napsal(a):<br>
> Hello Matej<br>
> <br>
> I spoke to the customer, who kindly provided the following source
on <br>
> github: </font></tt><a href="https://github.com/elexx/was9_bugs/tree/master/bug21"><tt><font size=2>https://github.com/elexx/was9_bugs/tree/master/bug21</font></tt></a><tt><font size=2><br>
> <br>
> It looks like the code is bound to a @PreDestroy method on the <br>
> @SessionScoped annotated class UserSessionData. The PreDestroy fires
<br>
> because session.invalidate() is called in LogoutServlet.<br>
> <br>
> Looking at <br>
> </font></tt><a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_contextit"><tt><font size=2>http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_contextit</font></tt></a><tt><font size=2>
<br>
> doesn't seem like any of the four cases when the spec applies here.
We <br>
> have left LogoutServlet's service() method before the new thread calls
<br>
> the preDestroy method. So I think this is an application issue.<br>
> <br>
> Regards<br>
> Benjamin<br>
> <br>
> <br>
> <br>
> From: Matej Novotny <manovotn@redhat.com><br>
> To: Benjamin Confino <BENJAMIC@uk.ibm.com><br>
> Cc: weld-dev@lists.jboss.org<br>
> Date: 12/06/2018 13:17<br>
> Subject: Re: [weld-dev] RquestScoped not active inside
<br>
> WeldInitialListener.requestDestroyed<br>
> ------------------------------------------------------------------------<br>
> <br>
> <br>
> <br>
> Hi,<br>
> <br>
> what does user code look like?<br>
> Does he have an event listener?<br>
> <br>
> I'd say this depends on *precisely* what is his code bound to.<br>
> At some point (after the invalidation), you should be getting <br>
> ContextNotActiveException so I guess we need to know more about the
code <br>
> to determine this.<br>
> If the user has some code bound to "generic" servlet events,
it may well <br>
> happen that they fire after CDI events.<br>
> <br>
> Matej<br>
> <br>
> ----- Original Message -----<br>
> > From: "Benjamin Confino" <BENJAMIC@uk.ibm.com><br>
> > To: weld-dev@lists.jboss.org<br>
> > Sent: Monday, June 11, 2018 10:46:31 AM<br>
> > Subject: [weld-dev] RquestScoped not active inside
<br>
> WeldInitialListener.requestDestroyed<br>
> ><br>
> > Hello.<br>
> ><br>
> > I have a customer who's getting ContextNotActiveExceptions
for the<br>
> > RequestScoped Context. This happens inside the invocation
of<br>
> > WeldInitialListener.requestDestroyed() after the customer's
application<br>
> > invalidated the session. DefaultLifecycleCallbackInvoker.invokeMethods<br>
> > invokes a method in application code, which calls a method
on a <br>
> proxy, which<br>
> > results in weld attempting to get the context from the
BeanManager <br>
> and the<br>
> > ContextNotActiveException.<br>
> ><br>
> > My question is simple. Is this an integration issue or
is this an <br>
> application<br>
> > issue?<br>
> ><br>
> > Here is the stack:<br>
> ><br>
> > org.jboss.weld.context.ContextNotActiveException: WELD-001303:
No active<br>
> > contexts for scope type javax.enterprise.context.RequestScoped<br>
> > at<br>
> > <br>
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:731)<br>
> > at<br>
> > <br>
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)<br>
> > at<br>
> > <br>
> org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164)<br>
> > at<br>
> > <br>
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)<br>
> > at<br>
> > <br>
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)<br>
> > at<br>
> > <br>
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)<br>
> > <CustomerClass>$$_WeldClientProxy.getUserId(Unknown
Source)<br>
> ><br>
> > <Application Code><br>
> ><br>
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)<br>
> > at<br>
> > <br>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)<br>
> > at<br>
> > <br>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)<br>
> > at java.lang.reflect.Method.invoke(Method.java:508)<br>
> > at<br>
> > <br>
> org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:97)<br>
> > at<br>
> > <br>
> org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:90)<br>
> > at<br>
> > <br>
> org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)<br>
> > at org.jboss.weld.bean.ManagedBean.destroy(ManagedBean.java:191)<br>
> > at<br>
> > <br>
> org.jboss.weld.util.bean.IsolatedForwardingBean.destroy(IsolatedForwardingBean.java:50)<br>
> > at<br>
> > <br>
> org.jboss.weld.context.AbstractContext.destroyContextualInstance(AbstractContext.java:139)<br>
> > at <br>
> org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:153)<br>
> > at<br>
> > <br>
> org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:58)<br>
> > at<br>
> > <br>
> org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)<br>
> > at<br>
> > <br>
> org.jboss.weld.servlet.HttpContextLifecycle.safelyDeactivate(HttpContextLifecycle.java:378)<br>
> > at<br>
> > <br>
> org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:311)<br>
> > at<br>
> > <br>
> org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:135)<br>
> > at<br>
> > <br>
> com.ibm.ws.webcontainer.managedobject.ManagedObjectListenerWrapper.requestDestroyed(ManagedObjectListenerWrapper.java:98)<br>
> > at<br>
> > <br>
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletRequestDestroyed(WebApp.java:2042)<br>
> > at<br>
> > <br>
> com.ibm.wsspi.webcontainer.collaborator.CollaboratorHelper.postInvokeCollaborators(CollaboratorHelper.java:532)<br>
> > at<br>
> > <br>
> com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1282)<br>
> > at<br>
> > <br>
> com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:82)<br>
> > at <br>
> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:963)<br>
> > at<br>
> > <br>
> com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1817)<br>
> > at<br>
> > <br>
> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:382)<br>
> > at<br>
> > <br>
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)<br>
> > at<br>
> > <br>
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:532)<br>
> > at<br>
> > <br>
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:318)<br>
> > at<br>
> > <br>
> com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:88)<br>
> > at<br>
> > <br>
> com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)<br>
> > at<br>
> > <br>
> com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)<br>
> > at<br>
> > <br>
> com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)<br>
> > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)<br>
> > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)<br>
> > at<br>
> > <br>
> com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)<br>
> > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)<br>
> > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1909)<br>
> ><br>
> > Unless stated otherwise above:<br>
> > IBM United Kingdom Limited - Registered in England and
Wales with number<br>
> > 741598.<br>
> > Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire <br>
> PO6 3AU<br>
> ><br>
> > _______________________________________________<br>
> > weld-dev mailing list<br>
> > weld-dev@lists.jboss.org<br>
> > </font></tt><a href="https://lists.jboss.org/mailman/listinfo/weld-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/weld-dev</font></tt></a><tt><font size=2><br>
> <br>
> <br>
> <br>
> <br>
> Unless stated otherwise above:<br>
> IBM United Kingdom Limited - Registered in England and Wales with
number <br>
> 741598.<br>
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU<br>
> <br>
> <br>
> _______________________________________________<br>
> weld-dev mailing list<br>
> weld-dev@lists.jboss.org<br>
> </font></tt><a href="https://lists.jboss.org/mailman/listinfo/weld-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/weld-dev</font></tt></a><tt><font size=2><br>
> <br>
<br>
-- <br>
Martin Kouba<br>
Senior Software Engineer<br>
Red Hat, Czech Republic<br>
<br>
</font></tt>
<br>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>