Pax Web the discovery of the Servlet Initializers seems to be fundamentally flawed.

103 views
Skip to first unread message

paul stanley

unread,
Oct 29, 2020, 9:13:21 AM10/29/20
to OPS4J

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

Grzegorz Grzybek

unread,
Oct 29, 2020, 9:28:05 AM10/29/20
to op...@googlegroups.com
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
 

--
--
------------------
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.

paul stanley

unread,
Oct 29, 2020, 2:17:19 PM10/29/20
to op...@googlegroups.com

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

Grzegorz Grzybek

unread,
Oct 29, 2020, 2:24:01 PM10/29/20
to op...@googlegroups.com
Hello

czw., 29 paź 2020 o 19:17 'paul stanley' via OPS4J <op...@googlegroups.com> napisał(a):

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.

It'd be great! I'm planning to get back to Pax Web 8 in ~2-3 weeks, but definitely won't spend >50% of my working time on it... I'm going to describe the undefined aspects in some place, so we know how it works by default and what could potentially be configurable.

regards
Grzegorz Grzybek

Matt Pavlovich

unread,
Oct 29, 2020, 2:50:19 PM10/29/20
to OPS4J
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.


-Matt

paul stanley

unread,
Oct 30, 2020, 4:43:30 AM10/30/20
to op...@googlegroups.com
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.
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 ops4j+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/a2363134-86ad-40e9-869b-36885ac68083n%40googlegroups.com.

Grzegorz Grzybek

unread,
Oct 30, 2020, 4:46:03 AM10/30/20
to op...@googlegroups.com
Hello

czw., 29 paź 2020 o 19:50 Matt Pavlovich <ma...@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
 

paul stanley

unread,
Nov 1, 2020, 12:56:56 PM11/1/20
to op...@googlegroups.com
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

Jean-Baptiste Onofré

unread,
Nov 1, 2020, 2:51:31 PM11/1/20
to OPS4J
Hi,

SpiFly can help, and you can always use direct war/webapp (not webbundle).

Regards
JB

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/0ba73d25-16c8-4ac6-8bfd-ad9404c56664%40googlemail.com.

Grzegorz Grzybek

unread,
Nov 2, 2020, 1:22:13 AM11/2/20
to op...@googlegroups.com
Hello

niedz., 1 lis 2020 o 18:56 'paul stanley' via OPS4J <op...@googlegroups.com> 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
 

paul stanley

unread,
Nov 6, 2020, 8:44:33 AM11/6/20
to op...@googlegroups.com
Thanks Grzegorz,

I'll have a more detailed look at this when I get back next week.

Regards
Paul

paul stanley

unread,
Nov 6, 2020, 8:44:33 AM11/6/20
to op...@googlegroups.com
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

Grzegorz Grzybek

unread,
Nov 6, 2020, 8:48:44 AM11/6/20
to op...@googlegroups.com
Hello!

pt., 6 lis 2020 o 14:44 'paul stanley' via OPS4J <op...@googlegroups.com> 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
 
Message has been deleted
Message has been deleted

paul stanley

unread,
Nov 15, 2020, 2:15:26 AM11/15/20
to op...@googlegroups.com
The initial issue that kicked off this thread was that, a 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.

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.

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.

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.

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.

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.

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.

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.  Any thoughts on such a solution?

Regards

Paul



Grzegorz Grzybek

unread,
Nov 16, 2020, 3:48:06 AM11/16/20
to op...@googlegroups.com
Hello! See my comments inline

niedz., 15 lis 2020 o 08:15 'paul stanley' via OPS4J <op...@googlegroups.com> 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

Christoph Läubrich

unread,
Nov 18, 2020, 2:23:07 AM11/18/20
to op...@googlegroups.com
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

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
> <op...@googlegroups.com <mailto:op...@googlegroups.com>> 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
> 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 gr.gr...@gmail.com
> Bundle *findEntries* method at
> <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> -
> 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
> <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/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> - 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/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>
> - 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/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> -
> 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/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> -
> 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/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> -
> op...@googlegroups.com <mailto: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
> <mailto:ops4j+un...@googlegroups.com>.
> 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> - 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
> <mailto:ops4j+un...@googlegroups.com>.
> 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>.

Grzegorz Grzybek

unread,
Nov 18, 2020, 2:39:52 AM11/18/20
to op...@googlegroups.com
Hello

śr., 18 lis 2020 o 08:23 'Christoph Läubrich' via OPS4J <op...@googlegroups.com> 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
 


---
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.

Christoph Läubrich

unread,
Nov 18, 2020, 2:54:22 AM11/18/20
to op...@googlegroups.com
At least here [1] it is listed as reference implementation, I don't
think that each release has to choose new reference implementations.

[1] https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html

Am 18.11.20 um 08:39 schrieb Grzegorz Grzybek:
> Hello
>
> śr., 18 lis 2020 o 08:23 'Christoph Läubrich' via OPS4J
> <op...@googlegroups.com <mailto:op...@googlegroups.com>> 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
> <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
> > <op...@googlegroups.com <mailto:op...@googlegroups.com>
> <mailto:op...@googlegroups.com <mailto:op...@googlegroups.com>>>
> >     <mailto:gr.gr...@gmail.com <mailto:gr.gr...@gmail.com>> wrote:
> >
> >         Hello!
> >
> >         pt., 6 lis 2020 o 14:44 'paul stanley' via OPS4J
> >         <op...@googlegroups.com <mailto:op...@googlegroups.com>>
> 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
> >             <gr.gr...@gmail.com <mailto:gr.gr...@gmail.com>> wrote:
> >
> >                 Hello
> >
> >                 niedz., 1 lis 2020 o 18:56 'paul stanley' via OPS4J <
> > op...@googlegroups.com <mailto:op...@googlegroups.com>> napisał(a):
> > gr.gr...@gmail.com <mailto:gr.gr...@gmail.com>> wrote:
> >
> >                         Hello
> >
> >                         czw., 29 paź 2020 o 19:50 Matt Pavlovich <
> > ma...@hyte.io <mailto:ma...@hyte.io>> napisał(a):
> <mailto: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
> > op...@googlegroups.com <mailto:op...@googlegroups.com>> napisał(a):
> >                                         <http://www.ops4j.org
> <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/e9d0b4ab-33d7-4895-8a0f-e6d55e3e3b43n%40googlegroups.com?utm_medium=email&utm_source=footer <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>
> >                                     <http://www.ops4j.org
> <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/CAAdXmhqcqH3h1bhJhYLb1%2B08u3dcSzFE%2BEYpe%2B62O7CbmMZHGQ%40mail.gmail.com?utm_medium=email&utm_source=footer <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>
> >                             <http://www.ops4j.org
> <http://www.ops4j.org>> - op...@googlegroups.com
> <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/a2363134-86ad-40e9-869b-36885ac68083n%40googlegroups.com?utm_medium=email&utm_source=footer <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>
> >                         <http://www.ops4j.org
> <http://www.ops4j.org>> - op...@googlegroups.com
> <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/CAAdXmhpRfntRwzx2oykWjf56AJtWPH2nFD59dfLBFWLO5NpCJA%40mail.gmail.com?utm_medium=email&utm_source=footer <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> <http://www.ops4j.org <http://www.ops4j.org>>
> >                     - op...@googlegroups.com
> <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/0ba73d25-16c8-4ac6-8bfd-ad9404c56664%40googlemail.com?utm_medium=email&utm_source=footer <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> <http://www.ops4j.org <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@googlegroups.com>.
> >                 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>
> >
>  <https://groups.google.com/d/msgid/ops4j/CAAdXmhpYfC1xBd2%3DXEGjHjut8wAb1rCc6GYmP%2B2PqTk6rLy%3DKQ%40mail.gmail.com?utm_medium=email&utm_source=footer <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>
> <http://www.ops4j.org <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@googlegroups.com>.
> >
> >             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>
> >
>  <https://groups.google.com/d/msgid/ops4j/38587571-05a7-4043-a381-f0a7ac6d50fb%40googlemail.com?utm_medium=email&utm_source=footer <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>
> <http://www.ops4j.org <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto:op...@googlegroups.com>
> <mailto:op...@googlegroups.com <mailto: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
> <mailto:ops4j%2Bunsu...@googlegroups.com>
> >     <mailto:ops4j+un...@googlegroups.com
> <mailto:ops4j%2Bunsu...@googlegroups.com>>.
> >     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>
> >
>  <https://groups.google.com/d/msgid/ops4j/629e8714-e364-4893-8e63-5b4291abca0an%40googlegroups.com?utm_medium=email&utm_source=footer <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>
> <http://www.ops4j.org <http://www.ops4j.org>> -
> op...@googlegroups.com <mailto: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
> <mailto:ops4j%2Bunsu...@googlegroups.com>
> > <mailto:ops4j+un...@googlegroups.com
> <mailto:ops4j%2Bunsu...@googlegroups.com>>.
> > 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>
>
> >
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrKq8UodOjM7ugnGeE9_FciVqATen63kZ0cPhO1bzKw%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrKq8UodOjM7ugnGeE9_FciVqATen63kZ0cPhO1bzKw%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org <http://www.ops4j.org> -
> op...@googlegroups.com <mailto: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
> <mailto:ops4j%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/bec95850-92c9-6bb9-3e16-bf419cbdd7c6%40googlemail.com
> <https://groups.google.com/d/msgid/ops4j/bec95850-92c9-6bb9-3e16-bf419cbdd7c6%40googlemail.com>.
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org <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
> <mailto:ops4j+un...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/CAAdXmhrEHyD-%3DMKNoDz9NogR1XGaUVjJSTRgjJ7W4Z6f3%3DXWSQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrEHyD-%3DMKNoDz9NogR1XGaUVjJSTRgjJ7W4Z6f3%3DXWSQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Christoph Läubrich

unread,
Nov 18, 2020, 3:06:41 AM11/18/20
to op...@googlegroups.com
I also added an extender for SPI implementations to Pax JPA that
discovers registered SPIs.

https://github.com/ops4j/org.ops4j.pax.jpa/blob/master/pax-jpa/src/main/java/org/ops4j/pax/jpa/impl/tracker/PersistenceProviderBundleTrackerCustomizer.java

Am 18.11.20 um 08:39 schrieb Grzegorz Grzybek:
> Hello
>
> śr., 18 lis 2020 o 08:23 'Christoph Läubrich' via OPS4J
> <op...@googlegroups.com <mailto:op...@googlegroups.com>> 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
> <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
> > <op...@googlegroups.com <mailto:op...@googlegroups.com>
> <mailto:op...@googlegroups.com <mailto:op...@googlegroups.com>>>
> >     <mailto:gr.gr...@gmail.com <mailto:gr.gr...@gmail.com>> wrote:
> >
> >         Hello!
> >
> >         pt., 6 lis 2020 o 14:44 'paul stanley' via OPS4J
> >         <op...@googlegroups.com <mailto:op...@googlegroups.com>>
> 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
> >             <gr.gr...@gmail.com <mailto:gr.gr...@gmail.com>> wrote:
> >
> >                 Hello
> >
> >                 niedz., 1 lis 2020 o 18:56 'paul stanley' via OPS4J <
> > op...@googlegroups.com <mailto:op...@googlegroups.com>> napisał(a):
> > gr.gr...@gmail.com <mailto:gr.gr...@gmail.com>> wrote:
> >
> >                         Hello
> >
> >                         czw., 29 paź 2020 o 19:50 Matt Pavlovich <
> > ma...@hyte.io <mailto:ma...@hyte.io>> napisał(a):
> <mailto: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
> > op...@googlegroups.com <mailto:op...@googlegroups.com>> napisał(a):
> >                                         <http://www.ops4j.org
> <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/e9d0b4ab-33d7-4895-8a0f-e6d55e3e3b43n%40googlegroups.com?utm_medium=email&utm_source=footer <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>
> >                                     <http://www.ops4j.org
> <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/CAAdXmhqcqH3h1bhJhYLb1%2B08u3dcSzFE%2BEYpe%2B62O7CbmMZHGQ%40mail.gmail.com?utm_medium=email&utm_source=footer <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>
> >                             <http://www.ops4j.org
> <http://www.ops4j.org>> - op...@googlegroups.com
> <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/a2363134-86ad-40e9-869b-36885ac68083n%40googlegroups.com?utm_medium=email&utm_source=footer <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>
> >                         <http://www.ops4j.org
> <http://www.ops4j.org>> - op...@googlegroups.com
> <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/CAAdXmhpRfntRwzx2oykWjf56AJtWPH2nFD59dfLBFWLO5NpCJA%40mail.gmail.com?utm_medium=email&utm_source=footer <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> <http://www.ops4j.org <http://www.ops4j.org>>
> >                     - op...@googlegroups.com
> <mailto: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 <mailto:ops4j%2Bun...@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>
> >
>  <https://groups.google.com/d/msgid/ops4j/0ba73d25-16c8-4ac6-8bfd-ad9404c56664%40googlemail.com?utm_medium=email&utm_source=footer <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> <http://www.ops4j.org <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@googlegroups.com>.
> >                 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>
> >
>  <https://groups.google.com/d/msgid/ops4j/CAAdXmhpYfC1xBd2%3DXEGjHjut8wAb1rCc6GYmP%2B2PqTk6rLy%3DKQ%40mail.gmail.com?utm_medium=email&utm_source=footer <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>
> <http://www.ops4j.org <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto: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 <mailto:ops4j%2Bun...@googlegroups.com>.
> >
> >             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>
> >
>  <https://groups.google.com/d/msgid/ops4j/38587571-05a7-4043-a381-f0a7ac6d50fb%40googlemail.com?utm_medium=email&utm_source=footer <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>
> <http://www.ops4j.org <http://www.ops4j.org>> -
> > op...@googlegroups.com <mailto:op...@googlegroups.com>
> <mailto:op...@googlegroups.com <mailto: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
> <mailto:ops4j%2Bunsu...@googlegroups.com>
> >     <mailto:ops4j+un...@googlegroups.com
> <mailto:ops4j%2Bunsu...@googlegroups.com>>.
> >     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>
> >
>  <https://groups.google.com/d/msgid/ops4j/629e8714-e364-4893-8e63-5b4291abca0an%40googlegroups.com?utm_medium=email&utm_source=footer <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>
> <http://www.ops4j.org <http://www.ops4j.org>> -
> op...@googlegroups.com <mailto: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
> <mailto:ops4j%2Bunsu...@googlegroups.com>
> > <mailto:ops4j+un...@googlegroups.com
> <mailto:ops4j%2Bunsu...@googlegroups.com>>.
> > 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>
>
> >
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrKq8UodOjM7ugnGeE9_FciVqATen63kZ0cPhO1bzKw%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrKq8UodOjM7ugnGeE9_FciVqATen63kZ0cPhO1bzKw%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org <http://www.ops4j.org> -
> op...@googlegroups.com <mailto: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
> <mailto:ops4j%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/bec95850-92c9-6bb9-3e16-bf419cbdd7c6%40googlemail.com
> <https://groups.google.com/d/msgid/ops4j/bec95850-92c9-6bb9-3e16-bf419cbdd7c6%40googlemail.com>.
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org <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
> <mailto:ops4j+un...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/CAAdXmhrEHyD-%3DMKNoDz9NogR1XGaUVjJSTRgjJ7W4Z6f3%3DXWSQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrEHyD-%3DMKNoDz9NogR1XGaUVjJSTRgjJ7W4Z6f3%3DXWSQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

paul stanley

unread,
Nov 18, 2020, 11:42:24 AM11/18/20
to op...@googlegroups.com

Thanks Christoph, I did something similar in my demo, where I used a bundle tracker in the api-web-api to return a list of SCIs.  This worked for my scenario in that it located and invoked the Jersey SCI that was deployed in a support bundle.  However as discussed in this thread, it isn’t really how services should be discovered in an OSGI environment.  

 

We do have the option to use the “OSGi ServiceLoader Mediator”(aka SPI-FLY) as pointed out above.  But I'm not a fan of needing to repackage bundles, to inject the capability headers to both the implementation and the client when you already have this information inside the bundle.  So I guess we’re back to using bespoke extenders. 


Also described in this thread, is the current work that Grzegorz is doing on pax-web version 8.  I’ve had a brief look at the code and he has reworked the SCI discovery mechanism.  I’ve yet to fully understand what he has done, but I believe that it keeps to the principle of only instancing SCI’s that are visible to the bundle. e.g. the dependencies of the WAB and pax-web bundles.  As such any bespoke solution may need to be reworked for the next revision of pax-web. 

 

Thanks for your input. 

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/b11af7e2-acf0-1fad-75c1-086dd1095af2%40googlemail.com.
Reply all
Reply to author
Forward
0 new messages