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(SlingBindings.class.getName()); SlingScriptHelper scriptHelper = bindings == null ? null :bindings.getSling(); SlingScript script = scriptHelper == null ? null : scriptHelper.getScript(); Resource scriptRes = script == null ? null : script.getScriptResource(); String scriptPath = scriptRes == null ? "n/a" : scriptRes.getPath(); */ While this doesn't use the request attribute, it is suffering from the same underlying issue. FWIW, the idea came up during the investigation of a similar (but more highly-integrated) debug/developer-mode facility. Cheers, Jeff. On 08/01/2014 00:06, "Alexander Klimetschek" <aklim...@adobe.com> wrote: >On 07.01.2014, at 11:19, Felix Meschberger <fmesc...@adobe.com> 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 be called is not available to the filters >>executed before calling the script. >> >> 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 ? > >I don't know any code using that attribute but thinking about it: > >It could only be an issue, if a filter relies on the fact that the >servlet name is NOT set (which would then always be the case atm, so it's >not really something where any meaningful logic could be behind). > >Or if the filter relies that it is from the previously executed servlet >(i.e. one that did an include or forward). Not sure if that is feasible... > >Finally, in our product code (Adobe CQ) I did not find a usage. > >So I would tend to say it's not a problem. It seems useful to make this >available to servlet filters that can do some aspect oriented handling >here, to e.g. process rendering resolution insights. > >OTOH, we already have the request progress tracker, might also make sense >to make individual entries more programmatically accessible. > >Cheers, >Alex
