Hi
Am 06.02.2014 um 11:18 schrieb Simone Tripodi <[email protected]>:
> Hi all mates,
>
> A colleague of mine just let me notice that from the sling
> ExecutionContextImpl implementation, it seems like resourceResolver could
> be null,
Well yes, that is how ExecutionContext.getResourceResolver is defined:
> /**
> * Returns a {@code ResourceResolver} object to retrieve information which
> * may influence the decision whether a {@link Feature} is enabled or not.
> * If a {@code ResourceResolver} object is not available in the context,
> * this method may return {@code null}.
> *
> * @return the resource resolver or {@code null}
> */
> ResourceResolver getResourceResolver();
>
> SlingAuthenticator gets control after the Feature’s filter & sets
> the resolver…
Can you provide a stack trace ? Thanks.
>
> Is there any way we can obtain the ResourceResolver before Feature’s filter
> is invoked?
The implementation is that the FeatureManager as a Filter is called before the
actual servlet (e.g. SlingMainServlet) is called for request processing. This
should actually also happen after authentication is handled.
The FeatureManager filter tries to extract the ResourceResolver from the
request attribute which is expected to be set by the Sling Authenticator. If
the request attribute is not available (or not a ResourceResolver instance),
the ExecutionCOntext will not provide a resource resolver.
Regards
Felix
>
> Many thanks in advance, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
