Re: Exposing RequestProgressTracker as ThreadLocal

2013-08-05 Thread Carsten Ziegeler
Yes, but why reinventing the wheel than rather do the right thing ?: ) Carsten 2013/8/5 Chetan Mehrotra > Well adding LogBack support might require more effort. What about > adding a Listener API and adding support for that in current logic. > That might be easier to add :) > > Chetan Mehrotra

Re: Exposing RequestProgressTracker as ThreadLocal

2013-08-05 Thread Chetan Mehrotra
Well adding LogBack support might require more effort. What about adding a Listener API and adding support for that in current logic. That might be easier to add :) Chetan Mehrotra On Mon, Aug 5, 2013 at 1:43 PM, Bertrand Delacretaz wrote: > On Mon, Aug 5, 2013 at 10:03 AM, Carsten Ziegeler >

Re: Exposing RequestProgressTracker as ThreadLocal

2013-08-05 Thread Bertrand Delacretaz
On Mon, Aug 5, 2013 at 10:03 AM, Carsten Ziegeler wrote: >> ...I was wondering where we are with [0] as well as I could make > use of it :) We're probably just missing a volunteer ;-) -Bertrand >> [0] http://markmail.org/message/etcayimn6ili3edr

Re: Exposing RequestProgressTracker as ThreadLocal

2013-08-05 Thread Carsten Ziegeler
2013/8/5 Bertrand Delacretaz > Yes, that's long overdue IMO, I could make good use of this for the > health check tool as well. > > We discussed this a few times already, and IIRC the conclusion was > that we should get rid of our custom logging implementation in favor > of logback (see [0] for e

Re: Exposing RequestProgressTracker as ThreadLocal

2013-08-05 Thread Bertrand Delacretaz
On Mon, Aug 5, 2013 at 9:36 AM, Chetan Mehrotra wrote: > ...If listener support can be added to Sling > logging then same thing (more powerful) can be achieved using MDC [1] > and Markers [2]... Yes, that's long overdue IMO, I could make good use of this for the health check tool as well. We dis

Re: Exposing RequestProgressTracker as ThreadLocal

2013-08-05 Thread Chetan Mehrotra
> 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

Re: Exposing RequestProgressTracker as ThreadLocal

2013-08-04 Thread Carsten Ziegeler
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 ne

Exposing RequestProgressTracker as ThreadLocal

2013-08-04 Thread Chetan Mehrotra
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 Re