openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "todor.dimitrov" <todor.dimit...@me.com>
Subject Re: CDI, Filter & Session-Scoped Bean
Date Wed, 30 Jan 2013 20:56:42 GMT
I guess this is the bug: in "initRequestContext" the session thread-local is not set to null
if the session is null and in "destroyRequestContext" the session thread-local is also not
cleared.


    private void initRequestContext(ServletRequestEvent event) {

        RequestContext rq = new ServletRequestContext();
        rq.setActive(true);

        requestContext.set(rq);// set thread local
        if (event != null) {
            HttpServletRequest request = (HttpServletRequest) event.getServletRequest();
            ((ServletRequestContext) rq).setServletRequest(request);

            if (request != null) {
                //Re-initialize thread local for session
                HttpSession session = request.getSession(false);

                if (session != null) {
                    initSessionContext(session);
                }

//                //Init thread local application context
//                initApplicationContext(event.getServletContext());
//
//                //Init thread local sigleton context
//                initSingletonContext(event.getServletContext());
            }
        }
    }

    private void destroyRequestContext() {
        if (supportsConversation()) { // OWB-595
            cleanupConversation();
        }

        //Get context
        RequestContext context = getRequestContext();

        //Destroy context
        if (context != null) {
            context.destroy();
        }

        // clean up the EL caches after each request
        ELContextStore elStore = ELContextStore.getInstance(false);
        if (elStore != null) {
            elStore.destroyELContextStore();
        }

        //Clear thread locals
        requestContext.set(null);
        requestContext.remove();

        //Also clear application and singleton context
//        applicationContext.set(null);
//        applicationContext.remove();

        //Singleton context
//        singletonContext.set(null);
//        singletonContext.remove();

        //Conversation context
        if (null != conversationContext) {
            conversationContext.set(null);
            conversationContext.remove();
        }

        RequestScopedBeanInterceptorHandler.removeThreadLocals();
    }




On 30.01.2013, at 21:31, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:

> Tomee uses cdiappcontextqsservice. Webbeanqcontextservice cant pass tcks
> 
> Le 30 janv. 2013 21:25, "todor.dimitrov" <todor.dimitrov@me.com> 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 <struberg@yahoo.de> 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 <bergmark@apache.org>
> >> To: user@openwebbeans.apache.org
> >> 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 <todor.dimitrov@me.com>
> >> 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 <bergmark@apache.org> 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
> >> <todor.dimitrov@me.com> 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"
> >> <todor.dimitrov@me.com> 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"
> >> <todor.dimitrov@me.com> 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
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> 


Mime
View raw message