Hmm, i think we must pass the HttpSession from
WebBeansConfigurationListener#sessionDestroyed to
WebContextsService#getSessionContext.
The current logic always gets the session from the request. This does of
course not work in this case.
Any idea to do this in a clean way and without ThreadLocal's or other hacks?


2013/4/16 Thomas Andraschko <[email protected]>

> Issue created -> https://issues.apache.org/jira/browse/OWB-841
>
>
> 2013/4/16 Thomas Andraschko <[email protected]>
>
>> Hey Mark,
>>
>> its not a exception, i just tracked the method calls :)
>> It's just the warning the i mentioned in the first mail.
>>
>> I will play a little bit and create a ticket. Maybe it's also related to
>> CODI, as i don't have a bean with @PreDestroy.
>>
>>
>> 2013/4/16 Mark Struberg <[email protected]>
>>
>>> yup thats right, there is something wrong.
>>> But there must be something special in your situation as I've never seen
>>> this in production yet.
>>>
>>> Can you please create a JIRA so we can track it?
>>> Please also add
>>>
>>> * which version of owb
>>> * which servlet container
>>> * some info whats going on in your thread
>>>
>>> > InjectionTargetProducer.preDestroy(InjectionTargetProducer.java:132)
>>> It seems that you have a @PreDestroy method which has a @SessionScoped
>>> bean as injection point.
>>> Can you please reduce your session timeout to 2 minutes and set a
>>> breakpoint to the place where the Exception gets thrown
>>> (WebContextsService.java:793)? And then you should be able to see which
>>> Bean did cause this problem if you go down call stack.
>>>
>>> And now some info about why I hacked the lazy session start:
>>> Initially we started the SessionContext for each and every request. But
>>> that means that we also did this for JSF Resource requests (png, css, etc)
>>> or other requests which simply don't need any session. To reduce the number
>>> of sessions we now only request one if a SessionScoped bean gets requested.
>>>
>>> This was especially hard in our case as we configured 1 node to only
>>> serve all the resources of our app (and all our other nodes only serve
>>> 'real' pages) - which was another nice speed bump ;)
>>> You can look at MyFaces / Jakob Korherrs staticresourcehandler if you
>>> have a performance intense app.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>   ------------------------------
>>>  *From:* Thomas Andraschko <[email protected]>
>>> *To:* [email protected]; Mark Struberg <[email protected]>
>>> *Sent:* Tuesday, 16 April 2013, 9:00
>>> *Subject:* Re: Could NOT lazily initialize session context because of
>>> null RequestContext
>>>
>>> Here is the stacktrace:
>>>
>>>     at
>>> org.apache.webbeans.web.context.WebContextsService.lazyStartSessionContext(WebContextsService.java:793)
>>>     at
>>> org.apache.webbeans.web.context.WebContextsService.getSessionContext(WebContextsService.java:708)
>>>     at
>>> org.apache.webbeans.web.context.WebContextsService.getCurrentContext(WebContextsService.java:248)
>>>     at
>>> org.apache.webbeans.context.ContextFactory.getStandardContext(ContextFactory.java:185)
>>>     at
>>> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:307)
>>>     at
>>> org.apache.webbeans.portable.creation.AbstractProducer.getCreationalContext(AbstractProducer.java:105)
>>>     at
>>> org.apache.webbeans.portable.creation.InjectionTargetProducer.preDestroy(InjectionTargetProducer.java:132)
>>>     at
>>> org.apache.webbeans.component.InjectionTargetWrapper.preDestroy(InjectionTargetWrapper.java:98)
>>>     at
>>> org.apache.webbeans.component.AbstractOwbBean.destroy(AbstractOwbBean.java:251)
>>>     at
>>> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:205)
>>>     at
>>> org.apache.webbeans.context.AbstractContext.destroy(AbstractContext.java:227)
>>>     at
>>> org.apache.webbeans.web.context.SessionContextManager.destroySessionContextWithSessionId(SessionContextManager.java:84)
>>>     at
>>> org.apache.webbeans.web.context.WebContextsService.destroySessionContext(WebContextsService.java:495)
>>>     at
>>> org.apache.webbeans.web.context.WebContextsService.endContext(WebContextsService.java:216)
>>>     at
>>> org.apache.webbeans.servlet.WebBeansConfigurationListener.sessionDestroyed(WebBeansConfigurationListener.java:197)
>>>     at
>>> org.eclipse.jetty.server.session.AbstractSessionManager.removeSession(AbstractSessionManager.java:801)
>>>     at
>>> org.eclipse.jetty.server.session.AbstractSession.timeout(AbstractSession.java:340)
>>>     at
>>> org.eclipse.jetty.server.session.HashSessionManager.scavenge(HashSessionManager.java:320)
>>>     at
>>> org.eclipse.jetty.server.session.HashSessionManager$2.run(HashSessionManager.java:282)
>>>     at java.util.TimerThread.mainLoop(Timer.java:555)
>>>     at java.util.TimerThread.run(Timer.java:505)
>>>
>>> It happens when the session expires.
>>> Any idea? IMO it should not try to lazy start a session if the session
>>> will be destroyed.
>>>
>>>
>>> 2013/4/12 Thomas Andraschko <[email protected]>
>>>
>>> Hi Mark,
>>>
>>> hmm, weird. I always get them at runtime. 7-8 times today. I only
>>> changed some pages and layout stuff and refreshed the page.
>>> Maybe it's because Jetty's change scanning.
>>> I will try it with Tomcat on Monday.
>>>
>>>
>>>
>>> 2013/4/12 Mark Struberg <[email protected]>
>>>
>>> Hi Thomas, this sometimes happens at container startup if the container
>>> code invokes some SessionScoped event. But the Session is only available in
>>> a request of course. this should be in the code already since a long time
>>> (1.1.2 or so)
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>   ------------------------------
>>>  *From:* Thomas Andraschko <[email protected]>
>>> *To:* [email protected]
>>> *Sent:* Friday, April 12, 2013 4:40 PM
>>> *Subject:* Could NOT lazily initialize session context because of null
>>> RequestContext
>>>
>>> Hi,
>>>
>>> i have many times this warning during development:
>>>
>>> WARNING: Could NOT lazily initialize session context because of null
>>> RequestContext
>>>
>>> Why does this occur and how can i avoid it?
>>> I never mentioned this error in my old application which runned
>>> perfectly with 1.1.6 (or 1.1.5, cant remember)
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Reply via email to