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. 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? BTW, how can i get the container reference from the ServletListenerProxy?. > 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.
