Hi Robert You are right. Reason of this « xml workaround » is that the service loader spec didn’t exist before OSGi r8.
So now that Karaf 4.5 is OSGi r8 we can revisit some impl we did. Regards JB Le dim. 24 sept. 2023 à 22:41, Robert Varga <n...@hq.sk> a écrit : > 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 >
