Another thing you could do is use byte code manipulation to change the ServiceLoader.load() callsite to use the MultiDelegationClassLoader instead of the original one classloader passed in. This would be similar to what SpiFly already does for the TCCL (it uses bytecode manipulation to set the TCCL), but then aimed at the ServiceLoader.load(Class, ClassLoader) API.
It would be a little bit of work, but if you're interested in looking at this I would be more than happy to help. In the end this solution would be nicer in that no fragments would be needed and you can use any combination of bundles to provide the service. Cheers, David On 5 November 2014 12:22, Charlie Mordant <[email protected]> wrote: > Considering the fact that I'm not a Deltaspike commiter, and that they don't > only target OSGI world, I'll opt for a fragment :). > > Thank you for your pointers, that will be useful for me in some future dev > for sure! > > Cheers, > Charlie > > 2014-11-05 13:06 GMT+01:00 David Bosschaert <[email protected]>: >> >> Right, so the Classloader passed in to ServiceLoader.load() does not >> have visibility of your additional bundle. >> >> There are a couple of things that you could do. If you can change the >> classloader passed in to ServiceLoader.load() you could pass in a >> MultiDelegationClassloader [1], which wraps both classloaders, both >> the original one and your new bundle. >> >> If you can't change the classloader passed in, I think the best option >> is a fragment... >> >> Cheers, >> >> David >> >> [1] >> https://svn.apache.org/repos/asf/aries/trunk/spi-fly/spi-fly-core/src/main/java/org/apache/aries/spifly/MultiDelegationClassloader.java >> >> On 5 November 2014 10:11, Charlie Mordant <[email protected]> wrote: >> > Hi David, >> > >> > The problem is that I'm trying to contribute a new service to load, but >> > from >> > another bundle (kind of Provider one), that is, this ServiceLoader.load >> > (Class, ClassLoader) won't see this extension. >> > May turning this provider to a Bundle Fragment could do the trick? >> > >> > Regards, >> > >> > >> > 2014-11-05 10:47 GMT+01:00 David Bosschaert >> > <[email protected]>: >> >> >> >> Hi Charlie >> >> >> >> On 5 November 2014 09:41, Charlie Mordant <[email protected]> wrote: >> >> > Hi again, >> >> > >> >> > Reading the docs, Aries spi-fly is only weaving >> >> > java.util.ServiceLoader#load(java.lang.Class) method signature. >> >> > Unfortunately, in deltaspike, they use >> >> > java.util.ServiceLoader#load(java.lang.Class, ClassLoader), where the >> >> > classloader used is the one from the ServiceUtils one (ds-api one). >> >> > >> >> > Is there a way to hack this? >> >> >> >> The main problem with ServiceLoader.load(Class) is that it uses the >> >> Thread Context Classloader to decide where to look for providers. >> >> >> >> When you're using ServiceLoader.load(Class, ClassLoader) you're >> >> already providing the classloader so at least the TCCL problem isn't >> >> there, so it may just work without SPI-Fly. If not, what is the >> >> remaining problem? If there is one, we should enhance SPI Fly to >> >> support it... >> >> >> >> Cheers, >> >> >> >> David >> > >> > >> > >> > >> > -- >> > Charlie Mordant >> > >> > Full OSGI/EE stack made with Karaf: >> > https://github.com/OsgiliathEnterprise/net.osgiliath.parent > > > > > -- > Charlie Mordant > > Full OSGI/EE stack made with Karaf: > https://github.com/OsgiliathEnterprise/net.osgiliath.parent
