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