OSGi / Spifly Provider for jakarta.ws.rs.ext.RuntimeDelegate cannot be found

[col-panic]

I have an OSGI environment with jersey-common 3.1.9, jakarta.ws.rs 3.1.0 and spifly 1.3.7

On startup console says

Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: Provider for jakarta.ws.rs.ext.RuntimeDelegate cannot be found
	at jakarta.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:118)
	at jakarta.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:88)
	at jakarta.ws.rs.core.Response$ResponseBuilder.newInstance(Response.java:776)
	at jakarta.ws.rs.core.Response.status(Response.java:522)
	at jakarta.ws.rs.core.Response.status(Response.java:533)
	at jakarta.ws.rs.core.Response.ok(Response.java:566)
	at ch.elexis.core.services.es.NoRemoteEventService.<init>(NoRemoteEventService.java:8)
	at ch.elexis.core.services.es.ElexisServerService.<init>(ElexisServerService.java:72)
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
	... 146 more
Caused by: java.lang.ClassNotFoundException: Provider for jakarta.ws.rs.ext.RuntimeDelegate cannot be found
	at jakarta.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:163)
	at jakarta.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:103)
	... 154 more

jakarta.ws.rs.ext.RuntimeDelegate is available within jersey-common and the /META-INF/services/jakarta.ws.rs.ext.RuntimeDelegate file exists.

It is, however, NOT being picked up by spifly. This is due to /META-INF/MANIFEST.MF not containing the required Require-Capability and Provide-Capability entries. See https://aries.apache.org/documentation/modules/spi-fly.html#specconf for details.

For example:

logback-classic correctly writes this info to MANIFEST-MF in https://github.com/qos-ch/logback/blob/5610c96b4d705a4fe6ded9c42d4f47cb92bbbd95/logback-classic/pom.xml#L343

while jersey-common does not do so in https://github.com/eclipse-ee4j/jersey/blob/d9658aa3064236abf1280f16e1705454e5d0b599/core-common/pom.xml#L150C25-L150C120

So adding the resp. extension should make OSGI Spifly pick up the required RuntimeDelegate and make it run, while it should not change behaviour for non-osgi uses of the bundle.

[senivam]

jakarta.ws.rs should be 3.1.0. Please check if it's not mistyped in your report or in the app (which is the worst case).

[col-panic]

jakarta.ws.rs should be 3.1.0. Please check if it's not mistyped in your report or in the app (which is the worst case).

Corrected, it is in fact jakarta.ws.rs-api 3.1.0

[senivam]

Thanks for the correction. Regarding the issue itself, Jersey already runs within at least a Glassfish OSGi environment, and there are no issues with it. We have never tried it with Spifly. It is probably possible to add those entries to comply with Spifly. This could be considered an enhancement for future releases.

[col-panic]

It might well be the case that it works in other OSGi environments, but I wonder on how the SPI implementation is detected. It did work with jakarta.ws.rs-api 2.1.6 where javax.ws.rs.ext.FactoryFinder seems to be implemented differently. All services, that get picked up correctly by SpiFly have the OSGi compatbiel annotation, another example is jakarta.xml.bind-api.jar - have a look at https://github.com/jakartaee/jaxb-api/blob/748c50bb8f71b4687febca5400fa9c574644aac3/api/pom.xml#L237

Do you know how Glassfish uses the ServiceLoader within its OSGi environment, because the problems should be the same?!

At the moment I am puzzled on how to fix this - as it would involve some weird classloading workarounds.

[senivam]

At the moment I am puzzled on how to fix this - as it would involve some weird classloading workarounds.

What comes to my mind is just forking the Jersey repo, fixing it in the branch, and using a snapshot instead. If you then provide a PR to the Jersey repo (requires signing of ECA), it would make the fix available in the nearest version of Jersey. Otherwise, we could fix that later.

[col-panic]

I made some progress here, and found out that every medal has two sites - lets sum it up

1. Spifly does dynamically modify java.util.Serviceloader
2. To have spifly intervene either bundle taking place in the process must opt-in for consuming and/or providing

So in my scenario, the following patch will provide mark the services to spifly

col-panic@0a5b19a

being jakarta.ws.rs.client.ClientBuilder in core-client and jakarta.ws.rs.ext.RuntimeDelegate and org.glassfish.jersey.internal.spi.AutoDiscoverable in core-common

BUT jakarta.ws.rs-api has to opt-in to spifly to consuming these services (if a single class is not mentioned, spifly will not inject it), which is done via a patch to another repostiory

col-panic/jax-ws-api@4e3cdba#diff-e55bdf06100eef1c252327789d9233a9f5fc308dc7f6b5e60caccaa6c3c44477R146 REF jakartaee/jax-ws-api#227

JAXB as Example

jakarta.xml.bind-api does set the Require-Capability in https://github.com/jakartaee/jaxb-api/blob/748c50bb8f71b4687febca5400fa9c574644aac3/api/pom.xml#L238
and jakarta jaxb-osgi does satisfy this in https://github.com/eclipse-ee4j/jaxb-ri/blob/b7d1ff7a13cecfaadde733387216b5cad09cc5b5/jaxb-ri/bundles/osgi/osgi/pom.xml#L295

This project simply seem to not yet have picked this up

For my test scenario the capabilities I mention here do suffice to make it run! I am sure, however, that for a proper patch we would have to expose all services that are somehow concered by jakarta.ws.rs.ext.FactoryFinder.

[senivam]

@col-panic - thanks for providing those patches and related info. Regarding the issue you are submitting to the jax-ws-api issue tracker - that is wrong API. You should submit the issue to the jakartaee/rest - that is the API Jersey implements.

[col-panic]

thanks @senivam for your feedback, this stuff keeps constantly confusing me, because somehow the patch there fixed the problem for me.

So to set this straight

• https://github.com/jakartaee/jax-ws-api = jakarta.xml.ws-api i.e. JAX-WS(Java API for XML Web Services)
• https://github.com/jakartaee/rest = jakarta.ws.rs-api i.e. JAX-RS (Java API for RESTful Web Services)
• https://github.com/jakartaee/jaxb-api = jakarta.xml.bind-api i.e. JAXB (Java XML Binding)

I see, somehow i mixed up my remotes - i will fix all of this and update the patches - might take some days....

[senivam]

yes, those URLs and descriptions you are providing:

• https://github.com/jakartaee/jax-ws-api = jakarta.xml.ws-api i.e. JAX-WS(Java API for XML Web Services)
• https://github.com/jakartaee/rest = jakarta.ws.rs-api i.e. JAX-RS (Java API for RESTful Web Services)

are correct.