[
https://issues.apache.org/jira/browse/SLING-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205372#comment-13205372
]
Felix Meschberger commented on SLING-2411:
------------------------------------------
> Yes, as I said, it was just a quick thought - but then using a thread local
> inside the resolver doesn't look right either
Oh ! Sorry. I didn't fully read this issue and proposal. No, I don't like this
thread local implementation proposal either.
Considering this and considering the request is not always available, I think I
favor an approach already mentioned: We deprecate the method with the request
argument (and might even define that null is always passed in). If a decorator
then requires access to the request, it is the task of that decorate to provide
the request, for example in a thread local provided by a filter.
Or Sling provides such a (component level) filter which provides service API to
get the current thread's request, response, and resource. This can be
implemented in a separate bundle, is not intrusive in existing code and would
provide actual data for all.
> 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
