Hello,now that we are going for Java 11, we need to deal with JPMS and the migration is showing some friction I have not seen in OpenDaylight.
OpenDaylight is a Karaf downstream, which requires Java 17 and is in a shape I would expect it to Just Work(tm) sans Karaf.
One of such points of friction is karaf.git/specs/java.xml -- which is overriding JVM classes.
As I understand it the point of this package override is to perform resolution to OSGi registry in service of https://issues.apache.org/jira/browse/KARAF-5680.
If my understanding is correct, everything we are overriding here could be just resolved via an OSGi-service loader. For example XMLInputFactory.newInstance() says, among JVM-defaults, this:
"Use the service-provider loading facility, defined by the ServiceLoader class, to attempt to locate and load an implementation of the service using the default loading mechanism: the service-provider loading facility will use the current thread's context class loader to attempt to load the service. If the context class loader is null, the system class loader will be used."
As I see it, we can satisfy the requirements of KARAF-5680 by saying the Karaf container always implements Service Loader Mediator Specification (https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.loader.html). In karaf.git terms, spifly is not a separate feature, but is always included in Karaf.
I mean, with JPMS, ServiceLoader is the platform-acknowledged extension mechanism, hence we should be integrating no matter what...
I this a sensible direction, or am I missing something? Regards, Robert
OpenPGP_signature
Description: OpenPGP digital signature
