Thanks Grzegorz. I know what you mean about doing my "normal job", I also have be careful as to what can be shared to the community.
I realise that the ServiceLoader is a bit of a problem and I've already had to alter other standard services to be bundle-aware. Which is why I think implementing a Bundle Listener could be a better approach for the SCI's. I'm out of the office for a couple of weeks so I'm going to look prototyping a solution when I get back. Cheers Paul On 29 Oct 2020, 13:28, at 13:28, Grzegorz Grzybek <[email protected]> wrote: >Hello > >You're generally right. I'm working on Pax Web 8 improvements (actual, >full >implementation of OSGi CMPN R6+ Whiteboard specification + HttpService >specification + Web Applications Specification) and I tackled the >problem >of ServletContainerInitializers. > >The problem is that OSGi CMPN spec doesn't mention SCIs at all, only >Web >Applications Specification generally assumes that "web bundle" should >be >processed ("extended") by the implementation which involves web.xml >parsing >+ fragments parsing + (possibly) "classpath scanning". See for example: > >A WAB can optionally contain a web.xml resource to specify additional >> configuration. This web.xml must be found with the Bundle >*findEntries* >> method at the path WEB-INF/web.xml. The findEntries method includes >> fragments, allowing the web.xml to be provided by a fragment. >> > >So here there's nothing about "scanning other bundles" not referred >through >"fragment" relationship. > >Also: > >Unlike a WAR, a WAB is not constrained to package classes and code >> resources in the WEB-INF/classes directory or dependent JARs in >> WEB-INF/lib/ only. These entries can be packaged in any way that's >valid >> for an OSGi bundle as long as such directories and JARs are part of >bundle >> class path as set with the Bundle-ClassPath header and any attached >> fragments. JARs that are specified in the Bundle-ClassPath header are >> treated like JARs in the WEB-INF/lib/ directory of the Servlet >> specification. Similarly, any directory that is part of the >> Bundle-ClassPath header is treated like WEB-INF/classes directory of >the >> Servlet specification. >> > >So again - you can "bring" additional libraries to your "bundle >classpath" >by referring them in "Bundle-ClassPath" header. No scanning of >everything >(that's for example tracked by BundleListener). > >And about java.util.ServiceLoader (which should in theory be a >suggestion >to how ServletContainerInitializer "services" are found), >"java.util.ServiceLoader#load(java.lang.Class<S>, >java.lang.ClassLoader)" >method simply uses the passed classLoader and the other "load()" >version >uses TCCL. Neither of these methods scan ALL classloaders (all bundles >in >OSGi). > >In Pax Web 8 I'm definitely going to solve this problem - for now, a >bundle >that registered "a context" >(org.osgi.service.http.context.ServletContextHelper) is an "entry >point" to >classLoader "mesh" where all are checked for SCIs. > >My Pax Web 8 refactoring is taking its shape at >https://github.com/ops4j/org.ops4j.pax.web/tree/master-improvements >branch, >but I have to do my normal job a bit ;) So please be patient. > >regards >Grzegorz Grzybek > > >czw., 29 paź 2020 o 14:13 'paul stanley' via OPS4J ><[email protected]> >napisał(a): > >> Hello. >> >> I'm tracing this through to try and understand why Jersey Servlet >> Initializer is not invoked for a pure Jaxrs applications running in >Karaf >> 4.3.0. >> >> It appears the way that the ServletContainerInitializerScanner in the >> pax-web-api has a fundamental design flaw when it searches bundles >for >> instances of the /META-INF/services/ >ServletContainerInitializerScanner >> file. Namely that it only searches dependent bundles of the one that >is >> being initialised. As the implementation of any service is meant to >be >> hidden by the API, it means that you will never be able to initialise >any >> web servlet. As such the pax-jetty-web adds the bodge of wiring-in >itself >> to all web-context so its contextInitializer code can be discovered, >but no >> other implementations. >> >> Rather than performing a bundle scan each time, surely jetty should >be >> implementing the bundle listener pattern and have the set of servlet >> initializers that are available in the platform? Or am I missing >something? >> >> Cheers, >> >> Paul >> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] >> >> --- >> You received this message because you are subscribed to the Google >Groups >> "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, >send an >> email to [email protected]. >> To view this discussion on the web visit >> >https://groups.google.com/d/msgid/ops4j/e9d0b4ab-33d7-4895-8a0f-e6d55e3e3b43n%40googlegroups.com >> ><https://groups.google.com/d/msgid/ops4j/e9d0b4ab-33d7-4895-8a0f-e6d55e3e3b43n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > >-- >-- >------------------ >OPS4J - http://www.ops4j.org - [email protected] > >--- >You received this message because you are subscribed to the Google >Groups "OPS4J" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to [email protected]. >To view this discussion on the web visit >https://groups.google.com/d/msgid/ops4j/CAAdXmhqcqH3h1bhJhYLb1%2B08u3dcSzFE%2BEYpe%2B62O7CbmMZHGQ%40mail.gmail.com. -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/720b9929-0a4d-4ab6-aaca-52e4bc55bc7b%40googlemail.com.
