Tomee uses cdiappcontextqsservice. Webbeanqcontextservice cant pass tcks Le 30 janv. 2013 21:25, "todor.dimitrov" <[email protected]> a écrit :
> The "WebBeansConfigurationListener" class doesn't get loaded and the > "WebContextsService#initRequestContext" > "WebContextsService#destroyRequestContext" methods are never called. Maybe > it's a configuration problem? TomEE+ 1.5.1 uses Tomcat 7, which is a > Servlet-3.0 container. Any ideas? Btw, I'm starting the server from Eclipse. > > 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 > >>>>> > >>>>> > >>>>> > >>> > >> > >
