Hello śr., 18 lis 2020 o 08:23 'Christoph Läubrich' via OPS4J < [email protected]> napisał(a):
> Not sure if it already was mentioned, but OSGi provides already a way to > interact with Java-SPI through the Service Loader Mediator Specification > [1]. > > [1] > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html Is Aries SPI-Fly an RI of this spec? in R7 version? regards Grzegorz Grzybek > > > Am 16.11.20 um 09:47 schrieb Grzegorz Grzybek: > > Hello! See my comments inline > > > > niedz., 15 lis 2020 o 08:15 'paul stanley' via OPS4J > > <[email protected] <mailto:[email protected]>> napisał(a): > > > > Hello, > > > > My initial issue was that pure JAXRS WABs fail to bootstrap karaf, > > where as they work as documented when deployed into the OSGi side of > > Glassfish.Glassfish may be a JakartaEE platform, but essentiality it > > is an OSGI framework running on Felix. Therefore, felix should also > > support the concept of dropping annotated applications into the > > framework that will be picked up and initialised by the relevant > > extender. > > > > > > "Glassfish may be a JakartaEE platform, but essentiality it is an OSGI > > framework running on Felix" - IMO this statement is wrong. OSGi is an > > implementation detail of Glassfish and not its deployment/programming > > model. Superior programming/deployment model is JavaEE and it has to be > > JavaEE compliant (as it's RI). > > > > So the fact that pure JAXRS WAB failed is Karaf or Pax-Web (or any other > > WAB extender you've added to Karaf) fault and not that Glassfish did > > something right. > > > > This process is complicated by the fact that JAXRS services are web > > applications that are bootstrapped by a method described in the > > Servlet 3 specification.This is achieved by the appropriate > > technology (i.e. CXF or Jersey) providing a > > ServletContainerInitializer that allows the service to examine > > application and decided if further action is required. > > > > > > And that's what I'm carefully tackling in Pax Web 8, master-improvements > > branch. ServietContainerInitializers were not implemented correctly in > > Pax Web 7 wrt to classloading. > > > > As discussed previously the ServletContainerInitializer's are > > discovered through the use of the Java Util ServiceLoader > > service.This means that the META-INF/services file needs to be > > visible and creatable by the application's class loader.Or via some > > other means, e.g. servlet, jsp and jsf implementations are supported > > by the pax-web-extender specifically wiring in the appropriate class > > loaders during the web context initialisation process. > > > > > > And in OSGi, being networking and not hierarchical classloader system > > needs to handle SCIs differently - we can't search entire network of > > classloaders, while it's easy with hierarchical model. > > > > As such I've been trying to understand how Glassfish achieved > > something similar in a felix container, without the need for the > > application to specify either the Jersey implementation or the > > auxiliary library that contained the SCI. > > > > > > As I've said - Felix is implementation detail and when you deploy a WAR > > into Glassfish, this WAR is not even aware that there's Felix/OSGi > > underneath. There's strict and well-defined classloader passed to > > ServetContext implementation being associated with the WAR and > > everything just works according to JavaEE. > > > > It turns out that GF is using a couple of tricks to construct a > > common classloader at runtime which contains dependencies on all > > bundles that offer services through the ServiceLoader framework.This > > is then used as the parent classloader when bootstrapping web and > > other types of services, thus decoupling the web framework > > implementation from the applications that use it. > > > > > > Exactly. But this doesn't mean that any bundle that you sneak into this > > Felix-under-Glassfish will be used as the bundle providing extensions to > > how SCIs are handled when you deploy a WAR into Glassfish ;) > > > > Personally I like this approach as it allows our framework engineer > > to maintain the platforms separately from application developers who > > only need be concerned with the business logic.Thus if we want to > > upgrade or change the implementation of a particular technology > > (e.g. JAXRS, Spring, JPA, XML/JSON Binding, etc…) then we can > > without the need to rebuild all of the applications that use it. > > > > > > That's rather a promise of JavaEE and it's not that easy with OSGi. I > > mean OSGi's promise to replace impl without changing API is even > > stronger, because it works at package level, not at API level (though > > OSGi "contracts" are supposed to move this up from package to > > set-of-packages level). > > > > As a demo I have extended the ServletContainerInitializerScanner in > > the pax-web-api to track bundles that provide the SCI via the > > service loader file.These are then returned to the > > JettyServerWrapper when it is creating the HttpServiceContext.The > > result is that JAXRS, WebSocket and Spring MVC applications are all > > correctly initialised without the need to hard code a specific > > implementation into the business logic bundles. > > > > > > Cool! That's a proof that original scanner in Pax Web 7 didn't work > > correctly. I'm working on this in Pax Web 8. > > > > I realise that bootstrapping services like this does not conform to > > the class loading concepts of the OSGI specification, however it > > does make Karaf more flexible when used as a service platform.As > > such, I believe that we should consider adding the option of a SCI > > Bundle Extender to the pax web offering. > > > > > > I'll try to make it as configurable as possible in Pax Web 8 - feel free > > to review master-improvements branch before it gets merged into master! > > > > regards > > Grzegorz Grzybek > > > > Regards > > > > Paul > > > > On Friday, November 6, 2020 at 1:48:44 PM UTC [email protected] > > <mailto:[email protected]> wrote: > > > > Hello! > > > > pt., 6 lis 2020 o 14:44 'paul stanley' via OPS4J > > <[email protected]> napisał(a): > > > > Thanks Grzegorz, > > > > I'll have a more detailed look at this when I get back next > > week. > > > > > > Sure! Looking forward to your findings ;) > > > > regards > > Grzegorz Grzybek > > > > > > Regards > > Paul > > On 2 Nov 2020, at 06:22, Grzegorz Grzybek > > <[email protected]> wrote: > > > > Hello > > > > niedz., 1 lis 2020 o 18:56 'paul stanley' via OPS4J < > > [email protected]> napisał(a): > > > > 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. > > > > > > JaxRS and SpringMVC were designed to work in JavaEE > > runtime (or just flat classpath for non servlet > > applications) which has well defined hierarchical > > ClassLoader model, so scanning for SCIs is easy - just > > start with current ClassLoader (assigned to the WAR for > > example) and walk through parents. > > > > OSGi has also (very) well defined ClassLoader model - > > but it's not hierarchical, it's _network_ bidirectional > > graph of ClassLoaders... > > > > > > 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? > > > > > > Hmm, I'm not sure I understand... SCI in onStartup() > > gets an instance of ServletContext and array of classes > > - it should not be bundle aware... > > > > > > 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. > > > > > > I'm not sure we can extend the WebExtender (quite low > > level framework) with some web framework (SpringMVC, > > JaxRS, Wicket, Tapestry, name it - all more high > level).... > > > > But fear not - the best way to detect proper SCIs (IMO) > > is simply to use WAB archives, so all jars from > > Bundle-ClassPath manifest header (which by default means > > all jars from /WEB-INF/lib of the bundle) are scanned > > for SCIs and web-fragment.xmls. > > > > regards > > Grzegorz Grzybek > > > > > > 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 > > < > 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 > > < > 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 > > <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 > > <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 > > <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 > > <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 <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 <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/CAAdXmhpYfC1xBd2%3DXEGjHjut8wAb1rCc6GYmP%2B2PqTk6rLy%3DKQ%40mail.gmail.com > > < > https://groups.google.com/d/msgid/ops4j/CAAdXmhpYfC1xBd2%3DXEGjHjut8wAb1rCc6GYmP%2B2PqTk6rLy%3DKQ%40mail.gmail.com?utm_medium=email&utm_source=footer > >. > > > > > > -- > > -- > > ------------------ > > OPS4J - http://www.ops4j.org <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/38587571-05a7-4043-a381-f0a7ac6d50fb%40googlemail.com > > < > https://groups.google.com/d/msgid/ops4j/38587571-05a7-4043-a381-f0a7ac6d50fb%40googlemail.com?utm_medium=email&utm_source=footer > >. > > > > -- > > -- > > ------------------ > > OPS4J - http://www.ops4j.org <http://www.ops4j.org> - > > [email protected] <mailto:[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] > > <mailto:[email protected]>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/ops4j/629e8714-e364-4893-8e63-5b4291abca0an%40googlegroups.com > > < > https://groups.google.com/d/msgid/ops4j/629e8714-e364-4893-8e63-5b4291abca0an%40googlegroups.com?utm_medium=email&utm_source=footer > >. > > > > -- > > -- > > ------------------ > > OPS4J - http://www.ops4j.org <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] > > <mailto:[email protected]>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/ops4j/CAAdXmhrKq8UodOjM7ugnGeE9_FciVqATen63kZ0cPhO1bzKw%3Dg%40mail.gmail.com > > < > https://groups.google.com/d/msgid/ops4j/CAAdXmhrKq8UodOjM7ugnGeE9_FciVqATen63kZ0cPhO1bzKw%3Dg%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/bec95850-92c9-6bb9-3e16-bf419cbdd7c6%40googlemail.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/CAAdXmhrEHyD-%3DMKNoDz9NogR1XGaUVjJSTRgjJ7W4Z6f3%3DXWSQ%40mail.gmail.com.
