Paul-- You might checkout a BundleTracker. A BundleTracker is ensured to get a callback for every bundle, regardless as to when your bundle started. With a BundleListener, there is a race condition that you may not be activated before some bundles that you care about.
ref: https://docs.osgi.org/specification/osgi.core/7.0.0/util.tracker.html#d0e52020 -Matt On Thursday, October 29, 2020 at 1:17:19 PM UTC-5 [email protected] wrote: > > 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, 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 >> >> <https://groups.google.com/d/msgid/ops4j/CAAdXmhqcqH3h1bhJhYLb1%2B08u3dcSzFE%2BEYpe%2B62O7CbmMZHGQ%40mail.gmail.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/a2363134-86ad-40e9-869b-36885ac68083n%40googlegroups.com.
