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 < ops4j@googlegroups.com> 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 <gr.grzy...@gmail.com> wrote: >> >> Hello >> >> czw., 29 paź 2020 o 19:50 Matt Pavlovich < m...@hyte.io> 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 >>> 8.apri...@googlemail.com 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 < gr.gr...@gmail.com> >>>> 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 < >>>>> op...@googlegroups.com> 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 - op...@googlegroups.com >>>>>> >>>>>> --- >>>>>> 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 ops4j+un...@googlegroups.com. >>>>>> 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 - op...@googlegroups.com >>>>> >>>>> --- >>>>> 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 ops4j+un...@googlegroups.com. >>>>> >>>> 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 - ops4j@googlegroups.com >>> >>> --- >>> 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 ops4j+unsubscr...@googlegroups.com. >>> 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 - ops4j@googlegroups.com >> >> --- >> 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 ops4j+unsubscr...@googlegroups.com. >> 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 - ops4j@googlegroups.com > > --- > 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 ops4j+unsubscr...@googlegroups.com. > 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 - ops4j@googlegroups.com --- 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 ops4j+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAB8EV3RwOvyXww2f_FaMwrjiAg%2BDKTvcAEdWeOV%2BJC2rCF0F_Q%40mail.gmail.com.
