Hi Harald, my comments inline :)
Am 26.07.2012 21:13, schrieb Harald Wellmann: > OSGi service injection and service publishing by means of CDI > annotations is now possible with Pax CDI 0.2.0-SNAPSHOT for non-web > applications. > > The next major step I'd like to take is to make this work for WABs, in > combination with Pax Web. > just one side node you are starting to make my day since this has been my top 1 on my wish list, thank you :D > I'm not sure if this can be achieved without creating some new > extension points in Pax Web, so in short, my questions are: > > 1) Does Pax Web offer hooks for other extenders to customize the web > app being published? not yet > > 2) If not, would this be a feasible extension? yes, unless we stick to the "ServletContextInitializers" > > Some background and ideas: > > Both Pax Web and Pax CDI use the extender pattern, listening to bundle > start events and checking if the bundle contains a web.xml or a > beans.xml, respectively. > > Pax CDI extends a bundle with a CDI container, Pax Web extends a > bundle with a servlet context and publishes it as a web application. > > For a CDI-enabled WAB, the two extenders have to be coordinated - it > is not enough to let them process the same bundle in arbitrary order, > or else the web context might be running and servicing requests before > the CDI container has been initialized, or the CDI container might not > be aware of web object injection targets like servlets and filters. > > To make this work, it might be sufficient for Pax Web to allow a > customizer to > > - add a ServletContextListener (or a ServletContextInitializer) > - replace the classloader to be used as web app classloader either way sound good, but the first one gives me a better "feeling" about it. > > Motivation for the context listener: > > Both OpenWebBeans and Weld require a context listener in web-only > environments (Tomcat, Jetty), whereas full Java EE 6 containers add > them automatically behind the scenes to bootstrap the CDI container. This should work already, for Servlet 3.0 this functionality was needed. One thing though right now we do have a issue with this part of "automagically" discovering ServletContextInitalizers for the Initializers of MyFaces. Reason still unknown has to be some classloader issue which is really hard to trace right now. > > Motivation for the classloader: > > The classloader for the CDI container must be able to see the extended > bundle, the CDI provider bundle and any bundles with CDI portable > extensions (including Pax CDI). Pax CDI builds a multi-bundle > delegating classloader and sets this as TCCL to make Weld and > OpenWebBeans happy - not very nice, but Weld and OpenWebBeans do not > provide any more OSGi-friendly SPIs at the moment. Sounds almost like the way the JSP and TagLib way of working around these types of things. Right now I have the gut-feeling we probably need both the classloader for visibility of needed jars and still the ServletContextInitializer for startup combining the two. > > Achim and other Pax Web champions, I'd love to hear your opinions on > this, as I'm not too intimate with Pax Web internals... > > Best regards, > Harald > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general -- ----- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
