Hi I don't think pumping up the log tracker to extract information more easily is a way to go: Other than having some kind of defined line format, the actual messages are just strings with not defined format at all. So relying on the format of the messages is depending on implementation details which is bound to fail sooner or later.
The problem at hand is really simple, so lets just keep it simple: I propose to set the "sling.core.current.servletName" attribute earlier in the process so that filters can leverage that value. I am not against exposing more exposing more internal state from the request processing for information purposes given reasonable use cases. Regards Felix Am 08.01.2014 um 03:51 schrieb Bertrand Delacretaz <bdelacre...@apache.org>: > Hi Jeff, > > On Wed, Jan 8, 2014 at 12:40 PM, Jeff Young <j...@adobe.com> wrote: >> ...I don't think it saves adding a new mechanism. The new mechanism's >> primary job is to weave the debug info into the rendered html so that it >> can be displayed client-side in the context of the portions of the page it >> rendered. That's the "highly-integrated" part.... > > Ok, there's two concerns there: > > 1) Adding info to the RequestProgressTracker, and maybe making that > easier to use > > 2) Weaving that info into the rendered html > > I suggest working with use cases and/or prototypes for both. > -Bertrand
