Thanks JB, I've had a look at the SPIFLY project and the associated OSGI spec. I'm not too sure why additional bundle headers are necessary, whilst we have bundles extenders. But I assume that just wiring classloaders together and the relying on the original ServiceLoader implementation.
I'll give this a go when I get back next week. Regards Paul Get TypeApp for Android On 1 Nov 2020, 19:51, at 19:51, "Jean-Baptiste Onofré" <[email protected]> wrote: >Hi, > >SpiFly can help, and you can always use direct war/webapp (not >webbundle). > >Regards >JB > >On Sun, Nov 1, 2020 at 6:56 PM 'paul stanley' via OPS4J < >[email protected]> wrote: > >> Hi Grzegorz, >> >> Sorry about the delay in getting back to you. >> >> I realise your concerns about sci's from different webapps >interfering >> with each other. However the SCI mechanism appears to be the way that >the >> other web technologies, such as JAXRS and SpringMVC have a chance to >detect >> and influence the creation of the servlet. >> >> Given that ServiceLoader architecture is being used, is it >unreasonable >> that all possible instances for the SCI get asked to look at the >bundle and >> initialize the context is appropriate? >> >> If not, then we need another way to extend the WebExtender with other >web >> frameworks, allowing them to get involved with servlet creation. >Which >> does not include altering the webapp in some OSGI specific way. >> >> Cheers >> Paul >> On 30 Oct 2020, at 08:46, Grzegorz Grzybek <[email protected]> >wrote: >>> >>> Hello >>> >>> czw., 29 paź 2020 o 19:50 Matt Pavlovich < [email protected]> napisał(a): >>> >>>> 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. >>>> >>> >>> It's not about bundle tracker or listener. Whiteboard implementation >uses >>> such tracker to ensure that when a bundle is gone, all associated >contexts >>> and web elements should be deregistered. >>> It's more about which bundles should be scanned for >>> ServletContainerInitializers. imagine you install two "sets" of >bundles >>> (e.g., Karaf features) - you don't want SCIs from one feature (web >>> application) to be used in another feature/web application... >>> >>> regards >>> Grzegorz Grzybek >>> >>> >>>> >>>> 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 >>>> ><https://groups.google.com/d/msgid/ops4j/a2363134-86ad-40e9-869b-36885ac68083n%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/CAAdXmhpRfntRwzx2oykWjf56AJtWPH2nFD59dfLBFWLO5NpCJA%40mail.gmail.com >>> ><https://groups.google.com/d/msgid/ops4j/CAAdXmhpRfntRwzx2oykWjf56AJtWPH2nFD59dfLBFWLO5NpCJA%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/0ba73d25-16c8-4ac6-8bfd-ad9404c56664%40googlemail.com >> ><https://groups.google.com/d/msgid/ops4j/0ba73d25-16c8-4ac6-8bfd-ad9404c56664%40googlemail.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/CAB8EV3RwOvyXww2f_FaMwrjiAg%2BDKTvcAEdWeOV%2BJC2rCF0F_Q%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/8abcf049-01f4-4447-9e2a-ac2754a79597%40googlemail.com.
