This happens on TomEE+ 1.5.1. I'll try debugging it. Thanks,
Todor On 30.01.2013, at 20:54, Mark Struberg <[email protected]> wrote: > 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 >>>>> >>>>> >>>>> >>> >>
