Hi, Am 02.09.2012 um 09:00 schrieb Chetan Mehrotra:
> At times while debugging we need to find the servlet class name which > handles a particular request. In a JEE based Web Application one can find > out that by looking at the web.xml. However in OSGi it becomes bit tricky > to find out the information easily. Some information is provided by the > "Http Whiteboard" WebConsole Plugin [1]. However it does not provide > information about servlets which are registered directly through > org.osgi.service.http.HttpService.registerServlet(String, Servlet, > Dictionary, HttpContext) method or servlets which are managed by other Fwk > like Sling Right. I created the "Http Whiteboard" plugin to see how and whether the whiteboard works. But maybe it is too short-sighted with respect to servlets and filters registered through the service. This is definitively something which should be improved. As to registration through other frameworks, particularly Sling: This is not something that we in the Apache Felix project can do much about (except for those servlets and filters registered through the HttpService (or ExtHttpService). Particularly in the case of Sling the servlets are only registered inside of Sling and not with the Http Service, that is the Http Service does not know anything about them. So I think these other frameworks should care to display that information and you should contact that community. > > In case of Felix HttpService implementation this information is present > with o.a.f.http.base.internal.handler.HandlerRegistry [2] so I had to use > Sling Script Console [3] with script [7] to extract that information. It > would useful if all this information is exposed as part of some WebConsole > plugin similar to "Http Whiteboard" plugin. I am not sure what would be the > best way to achieve that but if we have a WebConsole plugin which exposes > some sort of API to allow various sub systems to provide Servlet > registration info then it can be used to provide all the required > information at one place collected from various sources like > > 1. Http Whiteboard information exists > 2. HttpService handlerRegistry (possibly a super set of #1) +1, as I said > 3. SlingServletResolver [4] Problem of Sling. But I have been thinking about a plugin for that one where you could enter an URL (or path) and the plugin would return the candidate scripts and servlets and mark the selected one. > 4. Sling Filter Printer [5] > > At minimum having access to HandlerRegistry state via current Http > Whiteboard would also help. Information related to Sling can somewhat be > extracted from Recent Requests plugin [6] > > Thoughts? I am not sure whether it is possible at all to have a single plugin suitable for all of the Http Service plus any existing frameworks ... This would rather be something pluggable... Regards Felix > > Chetan Mehrotra > > [1] > https://github.com/apache/felix/blob/trunk/http/whiteboard/src/main/java/org/apache/felix/http/whiteboard/internal/manager/HttpWhiteboardWebConsolePlugin.java > > [2] > https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/handler/HandlerRegistry.java > > [3] https://github.com/chetanmeh/c/wiki/Sling-Script-Console > [4] > https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java > > [5] > https://github.com/apache/sling/blob/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/WebConsoleConfigPrinter.java > [6] http://sling.apache.org/site/monitoring-requests.html > > [7] > import org.osgi.service.http.HttpService > import org.osgi.framework.FrameworkUtil > import org.osgi.framework.Bundle > > def httpService = sling.getService(HttpService.class) > httpService.handlerRegistry.aliasMap.each{alias,servlet -> > Bundle bnd = FrameworkUtil.getBundle(servlet.class) > println "$alias : ${servlet.class.name} ($bnd.symbolicName)" > } --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
