[TRINIDAD-1273] Apply a request lifecuycle to ThreadLocals so that their contents don't leak across requests

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0.9-core, 1.2.9-core
• Fix Version/s: 1.2.10-core
• Component/s: Archetype
• 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
• Assignee: Matthias Wessendorf
• Reporter: Blake Sullivan
• Created: 20/Oct/08 20:43
• Updated: 27/Jan/10 08:46
• Resolved: 23/Oct/08 09:34

Description

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.