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.
