Return-Path: X-Original-To: apmail-openwebbeans-user-archive@www.apache.org Delivered-To: apmail-openwebbeans-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3C13CEBA0 for ; Wed, 30 Jan 2013 21:09:08 +0000 (UTC) Received: (qmail 76838 invoked by uid 500); 30 Jan 2013 21:09:08 -0000 Delivered-To: apmail-openwebbeans-user-archive@openwebbeans.apache.org Received: (qmail 76814 invoked by uid 500); 30 Jan 2013 21:09:08 -0000 Mailing-List: contact user-help@openwebbeans.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@openwebbeans.apache.org Delivered-To: mailing list user@openwebbeans.apache.org Received: (qmail 76806 invoked by uid 99); 30 Jan 2013 21:09:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jan 2013 21:09:08 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of todor.dimitrov@me.com designates 17.158.42.246 as permitted sender) Received: from [17.158.42.246] (HELO nk11p07mm-asmtp001.mac.com) (17.158.42.246) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jan 2013 21:09:00 +0000 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_x3BPnLfTq3ixezVyY16L+g)" Received: from [192.168.1.13] (dsdf-4db53062.pool.mediaWays.net [77.181.48.98]) by nk11p07mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MHG000JDIQ3XE90@nk11p07mm-asmtp001.mac.com> for user@openwebbeans.apache.org; Wed, 30 Jan 2013 21:08:33 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2013-01-30_07:2013-01-30,2013-01-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1301300165 From: "todor.dimitrov" Message-id: Subject: Re: CDI, Filter & Session-Scoped Bean Date: Wed, 30 Jan 2013 22:08:26 +0100 References: <1359575643.57814.YahooMailNeo@web28902.mail.ir2.yahoo.com> To: user@openwebbeans.apache.org In-reply-to: X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org --Boundary_(ID_x3BPnLfTq3ixezVyY16L+g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable This change in "initRequestContext" fixes the problem: if (session !=3D null) { initSessionContext(session); } else { sessionContext.set(null); } On 30.01.2013, at 21:56, "todor.dimitrov" 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. >=20 >=20 > private void initRequestContext(ServletRequestEvent event) { >=20 > RequestContext rq =3D new ServletRequestContext(); > rq.setActive(true); >=20 > requestContext.set(rq);// set thread local > if (event !=3D null) { > HttpServletRequest request =3D (HttpServletRequest) = event.getServletRequest(); > ((ServletRequestContext) rq).setServletRequest(request); >=20 > if (request !=3D null) { > //Re-initialize thread local for session > HttpSession session =3D request.getSession(false); >=20 > if (session !=3D null) { > initSessionContext(session); > } >=20 > // //Init thread local application context > // initApplicationContext(event.getServletContext()); > // > // //Init thread local sigleton context > // initSingletonContext(event.getServletContext()); > } > } > } >=20 > private void destroyRequestContext() { > if (supportsConversation()) { // OWB-595 > cleanupConversation(); > } >=20 > //Get context > RequestContext context =3D getRequestContext(); >=20 > //Destroy context > if (context !=3D null) { > context.destroy(); > } >=20 > // clean up the EL caches after each request > ELContextStore elStore =3D ELContextStore.getInstance(false); > if (elStore !=3D null) { > elStore.destroyELContextStore(); > } >=20 > //Clear thread locals > requestContext.set(null); > requestContext.remove(); >=20 > //Also clear application and singleton context > // applicationContext.set(null); > // applicationContext.remove(); >=20 > //Singleton context > // singletonContext.set(null); > // singletonContext.remove(); >=20 > //Conversation context > if (null !=3D conversationContext) { > conversationContext.set(null); > conversationContext.remove(); > } >=20 > RequestScopedBeanInterceptorHandler.removeThreadLocals(); > } >=20 >=20 >=20 >=20 > On 30.01.2013, at 21:31, Romain Manni-Bucau = wrote: >=20 >> Tomee uses cdiappcontextqsservice. Webbeanqcontextservice cant pass = tcks >>=20 >> Le 30 janv. 2013 21:25, "todor.dimitrov" a = =E9crit : >> 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. >>=20 >> Todor >>=20 >>=20 >>=20 >> On 30.01.2013, at 20:54, Mark Struberg wrote: >>=20 >> > 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 >> >> 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 = >> >> 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 = 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 >> >> 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" >> >> 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" >> >> 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 loggedInUser; >> >>>>> >> >>>>> public void doFilter(ServletRequest request, ServletResponse >> >> response, >> >>>>> FilterChain chain) throws IOException, ServletException { >> >>>>> >> >>>>> final User user =3D loggedInUser.get(); >> >>>>> if (user !=3D 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 =3D loadUserFromDB(...); >> >>>>> } >> >>>>> >> >>>>> public String logout() { >> >>>>> currentUser =3D 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 >> >>>>> >> >>>>> >> >>>>> >> >>> >> >> >>=20 >=20 --Boundary_(ID_x3BPnLfTq3ixezVyY16L+g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

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



<= div>
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 =3D= new ServletRequestContext();
        rq.setActive(true);
    =     requestContext.set(rq);// set thread local
        if = (event !=3D null) {
        =     ((ServletRequestContext) = rq).setServletRequest(request);

            if = (request !=3D null) {
              =   HttpSession session =3D request.getSession(false);
  =               if (session !=3D 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 =3D = getRequestContext();

        //Destroy context
        if = (context !=3D null) {
        = }
    =     // clean up the EL caches after each request
        = ELContextStore elStore =3D ELContextStore.getInstance(false);
        if = (elStore !=3D null) {
        }
    =     //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 !=3D 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 =E9crit :
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<= /a>
>> 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 =3D loggedInUser.get();
>>>>> if (user !=3D 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 =3D loadUserFromDB(...);
>>>>> }
>>>>>
>>>>> public String logout() {
>>>>> currentUser =3D 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
>>>>>
>>>>>
>>>>>
>>>
>>



= --Boundary_(ID_x3BPnLfTq3ixezVyY16L+g)--