myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Weßendorf (JIRA) <>
Subject [jira] Resolved: (TRINIDAD-1273) Apply a request lifecuycle to ThreadLocals so that their contents don't leak across requests
Date Thu, 23 Oct 2008 09:34:44 GMT


Matthias Weßendorf resolved TRINIDAD-1273.

       Resolution: Fixed
    Fix Version/s: 1.2.10-core
         Assignee: Matthias Weßendorf

> Apply a request lifecuycle to ThreadLocals so that their contents don't leak across requests
> --------------------------------------------------------------------------------------------
>                 Key: TRINIDAD-1273
>                 URL:
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Archetype
>    Affects Versions: 1.0.9-core, 1.2.9-core
>         Environment: All Web Servers that use thread pools and do not clean up ThreadLocals
before returning the threads to the pool.  This includes at least WLS and OC4J
>            Reporter: Blake Sullivan
>            Assignee: Matthias Weßendorf
>             Fix For: 1.2.10-core
>         Attachments: JIRA_1273_1291.patch
>   Original Estimate: 48h
>  Remaining Estimate: 48h
> Trinidad and Trinidad customers use ThreadLocals to track per-request state in several
instances.  Typically, a ThreadLocal is used because the consuming code does not have access
to the Request Object.  Even though, the Request Object is available off of the ExternalContext,
code that executes extremely early or late in the request lifecycle may not have access to
a FacesContext.
> The proposed solution is to add a org.apache.myfaces.trinidad.util.ThreadLocalUtils class
with a method:
>   public static <T> ThreadLocal<T> newRequestThreadLocal()
> That will create a ThreadLocal instance that will be reset by the Trinidad implementation
when the request finishes (using the same hook point that the Trinidad RequestContext uses
to clean itself up).  The trickiest part of the implementation is connecting the code that
causes the removal of the ThreadLocals (which exists in the impl package) with the code that
creates the ThreadLocals to be reset, which exists in the api package.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message