[
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
