-1 using thread local is very dangerous and can cause memory leaks
i strongly recommend to reconsider this approach. whenever i
encountered the problem that i need a resource resolver but did't had
the request handy - it was a flaw in my architecture of my classes.
regards, toby
On 2/14/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Currently we provide instances of the ResourceResolver interface through
> the SlingHttpServletRequest.getResourceResolver() method. In addition we
> have a JcrResourceResolverFactory interface in the jcr/resource module,
> which creates ResourceResolver instances.
>
> There may be cases, where we need a ResourceResolver instance but do not
> have the SlingHttpServletRequest object at hand and do not want to lock
> into the jcr/resource module and create new JCR sessions and
> ResourceResolver instances just to get at resources.
>
> So I propose we define a new ResourceResolverProvider interface in the
> Sling API:
>
> public interface ResourceResolverProvider {
>
> /**
> * Returns a ResourceResolver for the current execution context of the
> * caller or null if no ResourceResolver intance is currently
> available.
> */
> ResourceResolver getResourceResolver();
>
> }
>
> This interface would be extended by the current
> JcrResourceResolverFactory interface in the jcr/resource module. The
> JcrResourceResolverFactoryImpl implementation implements the
> getResourceResolver() method using ThreadLocal variables as follows:
>
> JcrResourceResolverFactoryImpl implements JcrResourceResolverFactory {
>
> private ThreadLocal<ResourceResolver> resolver;
>
> ResourceResolver getResourceResolver() {
> return resolver.get();
> }
>
> }
>
> The getResourceResolver(Session) method is redefined to return a
> resource resolver for the given session and to store it in the
> ThreadLocal if the ThreadLocal is not set yet. If the ThreadLocal is set
> and the session of the stored ResourceResolver and the session parameter
> are the same, the ThreadLocal is returned.
>
> To be able to cleanup the ThreadLocals a new release(ResourceResolver)
> is defined, which is required to be called for all ResourceResolver
> instances retrieved through getResourceResolver(Session).
>
> This way, the Sling Main servlet is able to create the ResourceResolver
> at the start of the request and remove it at the end. Any clients
> calling ResourceResolverProvider.getResourceResolver() during request
> processing will get the current request's ResourceResolver.
>
> WDYT ?
>
> Regards
> Felix
>
>
--
-----------------------------------------< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
