Hi
The Sling Engine sets the "sling.core.current.servletName" request attribute to
the name of the Servlet (absolut path in case of Scripts) before calling the
servlet or script. In essence this means tha the name of the servlet/script to
be called is not available to the filters executed befor
On 07.01.2014, at 11:19, Felix Meschberger wrote:
> The Sling Engine sets the "sling.core.current.servletName" request attribute
> to the name of the Servlet (absolut path in case of Scripts) before calling
> the servlet or script. In essence this means tha the name of the
> servlet/script to
I'm not sure what I think of that change due to the following points:
- Filters might override getAttribute and therefore could (at least
theoretically) break currently working functionality (code which would not
be harmful atm)
- All usecases I can imagine here are about introspection of what scri
Hi,
On Tue, Jan 7, 2014 at 8:19 PM, Felix Meschberger wrote:
> ...What about if me move setting the property to immediately before calling
> any filters (and resetting it after returning from all filter and script
> processing) ?
> Would that break existing functionality ?...
That shouldn't be
Hi Alex,
Me thinks you didn't look hard enough. ;)
Adobe CQ's WCMDebugFilter has the following (commented-out) code:
/*
Currently disabled because misleading information, because the
script name is set after the filter chain.
SlingBindings bindings = (SlingBindings)
req.getAttribute
On Wed, Jan 8, 2014 at 11:42 AM, Jeff Young wrote:
> ...FWIW, the idea came up during the investigation of a similar (but more
> highly-integrated) debug/developer-mode facility
IMO that kind of info should come from the RequestProgressTracker
instead of adding new mechanisms. This is a basic
Hi Bertrand,
I wouldn't be opposed to using a better-structured RequestProgressTracker
log. (I did originally look at the existing one, but wasn't too excited
about parsing it to get the info out.)
But I don't think it saves adding a new mechanism. The new mechanism's
primary job is to weave th
Hi Jeff,
On Wed, Jan 8, 2014 at 12:40 PM, Jeff Young 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.
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
On 08.01.2014, at 06:41, Felix Meschberger wrote:
> 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 forma
+1 for the proposed change to set the name earlier
Carsten
2014/1/9 Alexander Klimetschek
> On 08.01.2014, at 06:41, Felix Meschberger wrote:
>
> > 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,
11 matches
Mail list logo
