[
https://issues.apache.org/jira/browse/SLING-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-2411:
----------------------------------
Attachment: SLING-2411-jsedding.patch
I attached a patch to illustrate what I have in mind. Currently, I am not 100%
satisfied with the patch, but maybe someone has a good idea, how to address the
following issues.
1. The RequestScopedResourceResolverWrapper class needs to be exported from the
bundle, if it should be available for use by e.g. the ResourceDecoratorTracker.
Should it be in the API bundle or exported by the engine bundle (that's how
it's done in the patch)? My gut feeling is that the ResourceDecorator(Tracker)
does not actually belong into the jcr.resources bundle. This should become more
evident when the ResourceResolver is decoupled from the JCR-ResourceProvider
(see SLING-2396).
2. I'm not certain whether it can be dangerous/undesired that
RequestScopedResourceResolverWrapper redirects map(String) to map(Request,
String).
Eventually, if we decide to go down this route, it may make sense to allow
registering ResourceResolverDecorator services, in a similar way to the current
ResourceDecorator services. Curiously, I belive that the ResourceDecorator
mechanism could be fairly easily implemented as a ResourceResolverDecorator.
> 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
> Attachments: SLING-2411-jsedding.patch
>
>
> 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
