Hi Juanjo, Juanjo Vázquez schrieb: > Hi Felix, > > Maybe a listener -- say ServletListenerHelper -- could be added in Sling >> which listens for the various Servlet API EventListeners registered as >> OSGi services. Upon registration of such listeners, the >> ServletListenerHelper would call into the registerEventListener of the >> PAX WebContainer. Upon unregistration, the unregisterEventListener would >> be called. >> >> This could be implemented in its own bundle and would just require the >> PAX Web Extender to be installed into the framework. >> > > Good idea. There is no reason that ServletListenerHelper has to be an OSGi > service, right?. I mean, just a plain Java class. Great.
Correct. > > On the other hand, I´m afraid that I´m using the Sling Web launchpad. So, I > suposse that this changes everything. More below... > > One point comes to mind: If we are referring to the Standalone Sling >> Launcher, which includes PAX Web Server, everything is fine. A different >> issue occurrs in case the SLing Web App is used inside another servlet >> container. > > > I´m referring to the Sling Web launchpad. > > >> In this case, I would suspect to register a SerlvetListerProxy to the >> servlet container which forwards any events to registered Servlet API >> Listener services. Such a proxy would be registered through the Sling >> Web App's web.xml and would know the OSGi container to access the services. > > > Not sure if I understand you completely. You mean to register a servlet > listener through the web.xml that: > > 1. Just handle the servlet events and call to custom dedicated OSGi > services?, or > 2. Handle the events and throws OSGi events handled by Event Admin service? I would not use the OSGi Event Admin (it requires the use of other API instead of the Servlet API and it has performance "issues"). Therefore I would prefer plain Servlet API services -- for example, a ServletContextListener would be registered as a ServletContextListener service. > > BTW, how can i get the container reference from the ServletListenerProxy?. This is kind of a tricky part. Let me sketch, the setup: * The ServletListenerProxy implements all Servlet API listener services * The class is registered in the launchpad web app using the <listener> element as defined in the Servlet API Spec. * Upon context creation of the Sling Web App, the proxy places itself into the context as a context attribute. * When the SlingServlet is initialized it looks at the ServletContext for the ServletListenerProxy instance. It hands over the BundleContext of the system bundle, which is actually the result of calling getBundleContext() on the Felix instance (since the Felix class launching the framework is the system bundle). Using this BundleContext, the proxy would use ServiceTrackers for all Servlet API Listener services. * When a Servlet API event arrives, the proxy checks the respective ServiceTracker for services and forwards the event to the services. * When Sling is shutdown in the SlingServlet.destroy method, the proxy is also terminated and closes the ServiceTrackers. * Finally the proxy removes itself from the servlet context. I think this is rather simple for Sling -- a single class to create in Sling, a small extension to the web.xml of the launchpad and some glue code in the SlingServlet -- and for any listener implementations -- they just register as OSGi services. Regards Felix > > >> The ultimate goal is, that Servlet API listeners may just register >> themselves as OSGi services and from then on be fed with the respective >> events. >> >> WDYT ? > > > Yes, I suspect this would be the better. > > BR, > > Juanjo. >
