[spi-fly] Messing with a different classloader

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[spi-fly] Messing with a different classloader

Benjamin Edwards
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
Reply | Threaded
Open this post in threaded view
|

Re: [spi-fly] Messing with a different classloader

David Bosschaert
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


On 21 August 2016 at 17:47, Benjamin Edwards <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [spi-fly] Messing with a different classloader

Benjamin Edwards
I have since discovered that there is an open jira to make undertow OSGi compliant and the devs seem game. I think I'll recommend that they just just set the classloader they want to be the tccl, call serviceloader in the way I'd like and then restore the tccl.

I do however think it's a nice enhancement to spi-fly, and I haven't done anything with asm in ages so I will probably have a crack at a patch as a second order concern (and a handy backup if the direct route fails).

Thanks,
Ben