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 21:08:26 GMT
This change in "initRequestContext" fixes the problem:

if (session != null) {
	initSessionContext(session);
} else {
	sessionContext.set(null);
}



On 30.01.2013, at 21:56, "todor.dimitrov" <todor.dimitrov@me.com> wrote:

> 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