Hi Benjamin, Right now SPI-Fly only handles the setting of the TCCL for ServiceLoader.load(Class) calls or for other no-arg methods such as DocumentBuilderFactory.newInstance().
ServiceLoader.load(Class, ClassLoader) is not currently handled because it does not use the TCCL as you say. In that case the client side has consciously decided what classloader is to be used, but clearly its not the classloader that you want it to use... If its not possible to somehow influence the classloader that's being passed in to the ServiceLoader.load(Class, ClassLoader) call you're out of luck right now. It might be an interesting enhancement to SPI Fly, though. It should not be too hard to add this in as a feature. If you think it should be added the best thing would be to create a JIRA for it [1]. (BTW patches appreciated!) Best regards, David [1] https://issues.apache.org/jira/browse/ARIES On 21 August 2016 at 17:47, Benjamin Edwards <edwards.b...@gmail.com> wrote: > Hi, > > I am trying to use undertow (http://undertow.io) in an OSGi context. It > relies on xnio which uses a ServiceLoader to hook up to an xnio provider. I > can change the manifest easily enough such that Qthe provider is extended > by spi-fly and publishes a real OSGi service. The problem is on the > consuming side, they ServiceLoader.load(Class, Classloader) to locate the > provider, so the TCCL is never consulted and so the 'spec-compliant' > consumer headers can't help me. > > Are there and clever things I can do with spi-fly to make this work? At > this point I am somewhat sure that i will have to do some dirty byte > weaving myself to make this happen. > > Before someone mentions the pax tipi jars: I'm not interested. They don't > have the latest versions and I'd rather maintain a shim that a patch > (however stupid that may or may not be). > > Ben >
