#5384 add missing osgi capability info for spifly injection

[col-panic]

As described in #5834

[jansupol]

@col-panic why is this needed?
Section 13.3. Says:

Consumers are classes that are not OSGi aware and directly use the Service Loader API

But that is not Jersey. Jersey is OSGi-aware, see OsgiRegistry class that has OsgiServiceFinder to lookup for the services in an OSGi environment.

Jersey is using ServiceFinder class to lookup instead of using directly ServiceLocator. That has an OSGi-aware ServiceIteratorProvider at hand.

[col-panic]

It is tightly interconnted with jakartaee/rest#1308 - without this patch I can't seem to connect jakarta rest requiring the services provided by jersey! Only with both patches this and the one in jakartaee/rest repo I managed to get the entire functionality up and running in my Osgi environment! Despite jersey having the functionality jakarta rest seems not to?!

Do you see another solution?

[jansupol]

Is it not enough to make the API OSGi-aware?

[col-panic]

Is it not enough to make the API OSGi-aware?

This seems to be the preferred approach to do just that. Take a look at the first post in #5834 - I referenced other projects realizing this compatibility just by extending the MANIFEST with the adaptations proposed in this patch.

[jansupol]

@col-panic We have OSGi tests in Jersey using Felix. Some magic is used there if you care to look.

The PR you created adds some code that is not covered by tests, and we do not understand it. If later someone comes saying there needs to be done something differently, we have no possibility to decide if yes or no. So we need to understand what is it you do.