> I'm not 100% sure if this is a good thing; the resource resolver can be > used without a request,
I understand that hence the main ask was for RequestProgressTracker. And yes the debug logic would check its not null and then would log. Reason I asked for ResourceResolver is that at times I had a requirement to access the user identity associated with current request in layers deep down which does not have access to HttpServletRequest. For example in one case I had to make an outbound call to a third party server from within Sling and there I need to *propagate* current user identity. Only was possible for me was to expose the current request ResourceResolver as a ThreadLocal. > maybe defining a log category for this is all we need? Probably yes. I used RequestProgressTracker as it works and well integrated with WebConsole. If listener support can be added to Sling logging then same thing (more powerful) can be achieved using MDC [1] and Markers [2]. Possibly the ResourceResolver or JCR Session can possibly be passed as Marker instances and then listeners can filter log messages and handle them as required. [1] http://logback.qos.ch/manual/mdc.html [2] http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback Chetan Mehrotra On Mon, Aug 5, 2013 at 12:05 PM, Carsten Ziegeler <[email protected]> wrote: > 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]
