Thanks Matt. I had been iterating over the bundle list that is returned by BundleContext.getBundles. but the BundleTracker sounds like a more elegant solution.
On 29 Oct 2020, 18:50, at 18:50, Matt Pavlovich <[email protected]> wrote: >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 a topic in the >Google Groups "OPS4J" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/ops4j/hmpbC3-vM6I/unsubscribe. >To unsubscribe from this group and all its topics, 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. -- -- ------------------ 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/778c009f-6948-4b21-a241-be553749273d%40googlemail.com.
