[
https://issues.apache.org/jira/browse/SLING-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205364#comment-13205364
]
Julian Sedding commented on SLING-2411:
---------------------------------------
> A ResourceResolver is not bound to a request and thus using it for the
> factory sounds wrong.
I agree with this statement. Taking this a step further, maybe it would be
worthwhile to factor out the "resolve" and "map" methods into a different
service (something Vidar may already be doing in his work to decouple JCR from
the ResourceResolverFactory). The methods "resolve" and "map" seem to be
inherently about requests: they provide the plumbing to get from the "external"
address (i.e. URI) of a resource to the "internal" address (i.e. location in
Sling's resource tree).
Actually, this may be a topic for the list.
While the changes are fairly minimal in the patch, I don't like the approach. I
believe the ThreadLocals shouldn't be necessary. Rather, I considered wrapping
the ResourceResolver, so it can piggyback the request (of course this is
optional and not applicable to e.g. an administrative resource resolver). The
ResourceDecoratorTracker could then check if the ResourceResolver is an
instance of the respective wrapper, cast it and get the piggybacked request.
The natural place for this wrapping to happen would be in the SlingMainServlet,
just before the call to processRequest.
On the other hand, I'm not too keen to put more and more functionality into the
SlingMainServlet. So an alternative might be to wrap the Request (e.g. using a
Filter) and let the Request#getResourceResolver return a wrapped
ResourceResolver as explained above. I'm not yet sure how feasible this
approach is, because ideally the ResourceResolver would be wrapped before the
RequestData#initResource is called.
I've started working on a patch and hope to get this finished at the weekend.
I'm interested in reading your thoughts.
> ResourceDecorator(Resource, HttpServletRequest) doesn't get called
> consistently
> -------------------------------------------------------------------------------
>
> Key: SLING-2411
> URL: https://issues.apache.org/jira/browse/SLING-2411
> Project: Sling
> Issue Type: Improvement
> Reporter: Justin Edelson
>
> The ResourceDecorator currently has two methods:
> decorate(Resource)
> decorate(Resource, HttpServletRequest)
> The JcrResourceResolver uses the latter method when
> resolve(HttpServletRequest,String) is invoked. In all other cases, the former
> method is used. This behavior is correct.
> However, the JcrResourceResolver (and any future ResourceResolver
> implementation for that matter) really doesn't have any control over how it
> is invoked. For example, at present <sling:include> and <sling:forward> call
> resolve(String), not resolve(HttpServletRequest,String) (see
> http://s.apache.org/lL5). But even if we did a code audit within Sling and
> fixed all the cases like this, we don't have any control over downstream
> applications which may or may not invoke the two-argument resolve() method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
