Not for this product iteration unfortunately. But I have planned to make a month of OSS patches and contributions (ActiveMQ, Camel, Deltaspike) to correct some issues I filled, so why not contributing to spi-fly too :).
Best regards, Charlie 2014-11-05 14:13 GMT+01:00 David Bosschaert <[email protected]>: > 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 > -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
