#1304 add missing osgi capability info for spifly injection

[col-panic]

See https://github.com/jakartaee/rest/issues/1304

[spericas]

Any comments @jansupol ?

[col-panic]

I'm still in the process of intergrating this into our application, so I might identify an additional capability that needs to be added, yet for my unit tests the as-is does work!

[jansupol]

I do not understand this too much. I am not against this, but the description of the OSGi headers is unclear to me.

Jakarta REST and Jersey are used in GlassFish OSGi and Felix OSGi and these fields do not seem to be mandatory there. But other OSGi frameworks may behave differently.

Anyway, jakarta.ws.rs.sse.SseEventSource.Builder is missing in the RequiredCapabilities if RequiredCapabilities should be added.

[jansupol]

I suppose jakartaee:release-3.1.x is not the right branch to create this PR.

[col-panic]

I do not understand this too much. I am not against this, but the description of the OSGi headers is unclear to me.

Jakarta REST and Jersey are used in GlassFish OSGi and Felix OSGi and these fields do not seem to be mandatory there. But other OSGi frameworks may behave differently.

Anyway, jakarta.ws.rs.sse.SseEventSource.Builder is missing in the RequiredCapabilities if RequiredCapabilities should be added.

So I'm trying to describe it the way I understand this - If I get it wrong, please correct it:

We are using Eclipse Equinox (it's an Eclipse RCP application), which uses Apache Felix DS for Osgi Services. Your services are not picked up, as you either need entries in /OSGI-INF or need to register them programmatically using the BundleContext - this is where Apache Aries https://aries.apache.org/documentation/modules/spi-fly.html comes into play. It connects the Java ServiceLoader Pattern with OSGi services.

I don't know how Glassfish in combination with Felix does the injection, but for my scenario it works this way:

• You start the application, and you do an eager start of spifly and all bundles providing services (which is what this patch is about)
• spifly then picks those up and interconnects the components (every component has to opt-in to be considered by spifly)

My log shows this on startup

Feb. 04, 2025 7:39:29 AM org.apache.aries.spifly.BaseActivator log
INFORMATION: Registered provider org.glassfish.jersey.client.JerseyClientBuilder of service jakarta.ws.rs.client.ClientBuilder in bundle org.glassfish.jersey.core.jersey-client
Feb. 04, 2025 7:39:29 AM org.apache.aries.spifly.BaseActivator log
INFORMATION: Registered provider org.glassfish.jersey.internal.RuntimeDelegateImpl of service jakarta.ws.rs.ext.RuntimeDelegate in bundle org.glassfish.jersey.core.jersey-common
Feb. 04, 2025 7:39:29 AM org.apache.aries.spifly.BaseActivator log
INFORMATION: Registered provider org.glassfish.jersey.logging.LoggingFeatureAutoDiscoverable of service org.glassfish.jersey.internal.spi.AutoDiscoverable in bundle org.glassfish.jersey.core.jersey-common
Feb. 04, 2025 7:39:29 AM org.apache.aries.spifly.BaseActivator log
INFORMATION: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic

If I deactivate spifly or remove the Provide/Require-Capability, then this happens

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)

@jansupol I can certainly refactor the PR and provide it for the right branch - just give me the directions!

[col-panic]

I added a PR for main branch in https://github.com/jakartaee/rest/pull/1308 with some more documentation

[col-panic]

I suppose jakartaee:release-3.1.x is not the right branch to create this PR.

The reason I did this, is that my targetet production env uses 3.1 and I could straight test it. I also would need a backport for this then to 3.1

[jansupol]

The reason I did this, is that my targetet production env uses 3.1 and I could straight test it. I also would need a backport for this then to 3.1

So far we never provided a release of an older version of the API, if I can recall correctly. I hoped someone would chime in to point us to the 3.1 development branch, but release- looks more like a technical branch for the release. Perhaps we would need to create a new branch from a tag?