Am 22.10.14 um 10:52 schrieb Bertrand Delacretaz:
> Hi,
>
> On Wed, Oct 22, 2014 at 10:22 AM, Stefan Seifert <sseif...@pro-vision.de>
> wrote:
>> ...i propose to add a new feature to the Sling API and Sling Engine to
>> access to the current request via an OSGi service, using
>> a servlet filter and a thread local internally....
>
> +1 in principle, though as Carsten says we can implement this in the
> engine to avoid the filter.
>
>> ...we have already a comparable threadlocal concept for resource resolver
>> [3]...
>
> So maybe we should rather put a single"request context" object in a
> ThreadLocal, instead of having different objects manage their own
> thread local things?
>
> Something like
>
> public interface ThreadLocalContext {
> SlingHttpServletRequest getCurrentRequest();
> ResourceResolver getCurrentResourceResolver();
> ResourceResolver [] getActiveResourceResolvers();
> }
>
The resource resolver thread local works outside of a request, so I dont
think we should deprecate that and replace it with the above mechanism.
Let's keep things separate.
Carsten
> etc...we can then test and evolve this in a cleaner way than with code
> scattered around various classes.
>
> For backwards compatibility, we can deprecate [3] and let it use this
> new API for now.
>
> -Bertrand
>
> [3]
> http://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceResolverFactory.html#getThreadResourceResolver--
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
