agree, this smells fishy so to say ;) On which server does this happen? Native Tomcat + OWB? The ThreadLocal which holds the current RequestContext is set in WebBeansConfigurationListener#requestInitialized.
Please set a breakpoint to see whether this gets invoked properly. This should finally invoke the WebContextsService#startContext and at the end of the request the ThreadLocal will be reset to null (and removed) in WebContextsService#destroyRequestContext Maybe you can debug into this and check whether you get the correct RequestContext? LieGrue, strub ----- Original Message ----- > From: Joseph Bergmark <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, January 30, 2013 7:55 PM > Subject: Re: CDI, Filter & Session-Scoped Bean > > Correct, there should not be thread locals leaking between requests. > > On Wed, Jan 30, 2013 at 1:51 PM, todor.dimitrov <[email protected]> > wrote: >> Just to be clear, this is not the expected behavior, right? The code should > be working as is? >> >> Thanks for the prompt response, >> >> Todor >> >> >> On 30.01.2013, at 19:45, Joseph Bergmark <[email protected]> wrote: >> >>> I would be surprised if it was randomly grabbing another session. >>> >>> My guess is that either the WebContextService threadlocals are leaking >>> the contexts themselves, or the threadlocal where we hold onto the the >>> request in order to lazy initialize the session is leaking, otherwise >>> I would expect you would receive a ContextNotActive exception if >>> Session was active on the current request thread. >>> >>> Sincerely, >>> >>> Joe >>> >>> On Wed, Jan 30, 2013 at 12:53 PM, todor.dimitrov > <[email protected]> wrote: >>>> Another follow up, >>>> >>>> if I add >>>> >>>> ((HttpServletRequest)request).getSession(true) >>>> >>>> at the beginning of the the doFilter method, then everything works > as >>>> expected and the previously described behavior is never observed. > This means >>>> that whenever the CDI implementation (OpenWebBeans) cannot retrieve > the >>>> session of the current web request, it injects a wrong object (i.e. > an >>>> object belonging to another session). >>>> >>>> >>>> On 30.01.2013, at 17:55, "todor.dimitrov" > <[email protected]> wrote: >>>> >>>> Hallo again, >>>> >>>> I've just noticed that when this behavior is observed the > session associated >>>> with the HTTPServletRequest is null. Somehow Tomcat cannot create a > session >>>> object for the request (normally a StandardSession object is > associated with >>>> the request). IMHO CDI shouldn't inject an object instance from > some other >>>> session if the session of the request is null. >>>> >>>> >>>> >>>> On 30.01.2013, at 17:39, "todor.dimitrov" > <[email protected]> wrote: >>>> >>>> Hallo, >>>> >>>> I have a weird problem when injecting a bean inside a servlet > filter, which >>>> is produced by a method of a session-scoped bean: >>>> >>>> Filter: >>>> >>>> public class AuthenticationFilter implements Filter { >>>> >>>> @Inject >>>> @LoggedIn >>>> private Instance<User> loggedInUser; >>>> >>>> public void doFilter(ServletRequest request, ServletResponse > response, >>>> FilterChain chain) throws IOException, ServletException { >>>> >>>> final User user = loggedInUser.get(); >>>> if (user != null) { >>>> // proceed ... >>>> } else { >>>> // redirect to login ... >>>> } >>>> } >>>> >>>> ... >>>> } >>>> >>>> Session-scoped bean with producer method: >>>> >>>> @Named >>>> @SessionScoped >>>> public class Login implements Serializable { >>>> >>>> private User currentUser; >>>> >>>> public String login() { >>>> currentUser = loadUserFromDB(...); >>>> } >>>> >>>> public String logout() { >>>> currentUser = null; >>>> } >>>> >>>> @Produces >>>> @LoggedIn >>>> public User getLoggedInUser() { >>>> return currentUser; >>>> } >>>> } >>>> >>>> Qualifier: >>>> >>>> @Target({ ElementType.FIELD, ElementType.METHOD }) >>>> @Qualifier >>>> @Retention(RetentionPolicy.RUNTIME) >>>> public @interface LoggedIn { >>>> } >>>> >>>> Sometimes the filter incorrectly retrieves the user instance from > some other >>>> active session. This happens, however, only the first time the page > is >>>> requested by the browser. On subsequent page reloads, the filter > recognises >>>> that the user is not logged in. It should be noted that the JSF >>>> implementation (MyFaces) ALWAYS uses the correct instance of the >>>> session-scoped bean. I've tried to inject the Login bean > instead of the User >>>> object but the result is the same. >>>> >>>> Do you have any clues to why I might be experiencing such a > behavior? >>>> >>>> >>>> Thanks in advance, >>>> >>>> Todor >>>> >>>> >>>> >> >
