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
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
>
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
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
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
> 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
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
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