> 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). The ResourceResolver javadocs suggest this as well, regarding "resolve": "This kind of method is intended to resolve request URLs to resources."
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.