When separating the api and the implementation, the service loader was introduced. This perfectly well suited mechanism is known to have problems in OSGi environments.
To overcome this, 4d84d6b added the hk2osgi service locator, which requires lots of special coding.
The problem has actually successfully been addressed before by http://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.loader.html with the reference implementation (with an easier to read description) SPI Fly. What it boils down to is that instead of having to maintain the complicated code, you can simply use the service locator after adding some statements to MANIFEST.MF.
While these is not a runtime bug, because you can use Jakarta activation in an OSGi environment (once you have found out that you need to include the hk2 jar), I think it is a bug with respect to the design.
When separating the api and the implementation, the service loader was introduced. This perfectly well suited mechanism is known to have problems in OSGi environments.
To overcome this, 4d84d6b added the hk2osgi service locator, which requires lots of special coding.
The problem has actually successfully been addressed before by http://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.loader.html with the reference implementation (with an easier to read description) SPI Fly. What it boils down to is that instead of having to maintain the complicated code, you can simply use the service locator after adding some statements to MANIFEST.MF.
While these is not a runtime bug, because you can use Jakarta activation in an OSGi environment (once you have found out that you need to include the hk2 jar), I think it is a bug with respect to the design.