I'm not 100% sure if this is a good thing; the resource resolver can be used without a request, the resource api is not tied to to request/response handling, so with this you add a dependency between resource providers and the Sling engine. At the bare minimum, before using the tracker you would need to check whether it is available.
If we would do this, we don't need an additional filter, the Sling engine could do this internally. As this is about resource resolving and finding out what's going on there, I'm wondering if a separate tracker for this would make sense and then finding a way to attach it's output the the request progress tracker. But maybe defining a log category for this is all we need? Regards Carsten 2013/8/5 Chetan Mehrotra <[email protected]> > Hi, > > Sling RequestProgressTracker is a valuable feature which helps in > understanding the request flow easily. I tried using it for logging > calls made to MongoDB server for a given thread [1] and it gives a > very good insight in what is happening. As such component do not have > direct access to the RequestProgressTracker or ResourceResolver > associated with current request I had to expose it via ThreadLocal. > > It would be helpful if we can have a Sling Filter and API which > exposes the current thread's RequestProgressTracker (or better > ResourceResolver!!). Such API would allow creating debugging > components which can say track JCR session operations performed in a > given request. > > Thoughts? I can create a patch if people consider it as a good thing > to have as part of Sling. > > [1] https://github.com/chetanmeh/mongo-sling-tracer > > Chetan Mehrotra > -- Carsten Ziegeler [email protected]
