Skip to content

Conversation

@col-panic
Copy link

See #1304

@spericas
Copy link
Contributor

spericas commented Feb 3, 2025

Any comments @jansupol ?

@col-panic
Copy link
Author

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
Copy link
Contributor

jansupol commented Feb 3, 2025

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
Copy link
Contributor

jansupol commented Feb 3, 2025

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

@col-panic
Copy link
Author

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
Copy link
Author

I added a PR for main branch in #1308 with some more documentation

@col-panic
Copy link
Author

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
Copy link
Contributor

jansupol commented Feb 4, 2025

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants