2018-03-28 16:16 GMT+02:00 Daniel Kulp <dk...@apache.org>: > > > > On Mar 27, 2018, at 10:48 AM, Guillaume Nodet <gno...@apache.org> wrote: > > > > I've created a PR with a solution that works on both java 8 and java 9. > > Basically, we do something similar than with the servicemix specs, but > in a > > more focused way, i.e. we only add the classes that need to be overriden. > > See https://github.com/apache/karaf/pull/481 > > That’s kind of cool. This would just apply to the specs that are > available as part of the JDK, right? So not needed for things like > JAX-RS? We’d use the normal specs bundles for those? > > Yes, because we only includes the api classes that are factories in order to overwrite the JDK ones.
Guillaume > > Dan > > > > > > > 2018-03-23 14:30 GMT+01:00 Guillaume Nodet <gno...@apache.org>: > > > >> So I think we don't have to transform the servicemix specs into java > >> modules, but we can actually use the --patch-module option to hack the > >> content of the JVM modules and use the servicemix classes instead. > >> However, it does not work well for all specs, we need to abide to the > JVM > >> modules boundaries. > >> For example the jaxp spec is split into java.xml and jdk.java.xml and > >> trying to use the jaxp servicemix spec does not work because it crosses > >> both modules. > >> I'll continue investigating, but that seems like a solution which could > >> work on both java 8 and java 9. > >> > >> Guillaume > >> > >> > >> 2018-03-22 21:14 GMT+01:00 Guillaume Nodet <gno...@apache.org>: > >> > >>> Unfortunately, using spi-fly won't work, or not very well. > >>> The reason is that spi-fly do some weaving to fix the > >>> ServiceLoader.load() calls. > >>> In the case of woodstox, the call is done from > >>> XMLInputFactory#newInstance, which resides in the stax api package. > >>> So we'd have to deploy the servicemix specs as a bundle in order to > weave > >>> it, but that would preclude the use of the default providers. > >>> So I think the best option is what I had envisioned months ago (but > kinda > >>> differed working on it), i.e. enhance the servicemix specs so that they > >>> become java modules. > >>> That's the new way to replace the endorsed lib mechanism, and I think > >>> we'll have to use it. > >>> I'm going to investigate this issue a bit this week or the next... > >>> > >>> Guillaume > >>> > >>> > >>> > >>> 2018-03-22 18:32 GMT+01:00 Guillaume Nodet <gno...@apache.org>: > >>> > >>>> I see several options: > >>>> - using aries spi-fly > >>>> - deploy the smx specs as java modules > >>>> - deploy the provider as a java module > >>>> - instantiate the provider explicitely from the consumer > >>>> > >>>> I'm going to investigate, but the easier might be to use spi-fly. It > >>>> would require 2 fragments (or modifications), but this is not a > generic > >>>> solution: each provider / consumer has to be extended in some way to > opt-in. > >>>> > >>>> Also, things like javamail might get a bit tricky... > >>>> > >>>> > >>>> 2018-03-01 8:04 GMT+01:00 Siano, Stephan <stephan.si...@sap.com>: > >>>> > >>>>> Hi, > >>>>> > >>>>> Till Karaf 4.1.x the endorsed libs delivered with karaf contain some > >>>>> servicemix wrapped bundles for standard javax APIs. An example for > this is > >>>>> the Stax API (javax.xml.stream). These wrapped API bundles replace > the > >>>>> implementation lookup mechanism provided by the JDK with one also > working > >>>>> in an OSGi environment. > >>>>> > >>>>> With Karaf 4.2.0 these endorsed libraries were removed (because Java > 9 > >>>>> does not support endorsed libraries anymore). What is the idea how > it might > >>>>> still be possible to run Karaf 4.2.x with the woodstox Stax > implementation? > >>>>> > >>>>> If you just install the woodstox-bundles as with karaf 4.1.x, you > will > >>>>> get the following exception: > >>>>> java.util.ServiceConfigurationError: javax.xml.stream. > XMLInputFactory: > >>>>> Provider com.ctc.wstx.stax.WstxInputFactory not found > >>>>> at java.util.ServiceLoader.fail( > ServiceLoader.java:239) > >>>>> at java.util.ServiceLoader.access > >>>>> $300(ServiceLoader.java:185) > >>>>> at java.util.ServiceLoader$LazyIt > >>>>> erator.nextService(ServiceLoader.java:372) > >>>>> at java.util.ServiceLoader$LazyIt > >>>>> erator.next(ServiceLoader.java:404) > >>>>> at java.util.ServiceLoader$1.next > >>>>> (ServiceLoader.java:480) > >>>>> at javax.xml.stream.FactoryFinder > >>>>> $1.run(FactoryFinder.java:353) > >>>>> at java.security.AccessController.doPrivileged(Native > >>>>> Method) > >>>>> at javax.xml.stream.FactoryFinder > >>>>> .findServiceProvider(FactoryFinder.java:341) > >>>>> at javax.xml.stream.FactoryFinder > >>>>> .find(FactoryFinder.java:313) > >>>>> at javax.xml.stream.FactoryFinder > >>>>> .find(FactoryFinder.java:227) > >>>>> at javax.xml.stream.XMLInputFacto > >>>>> ry.newFactory(XMLInputFactory.java:205) > >>>>> > >>>>> Is there any idea how this might work? I am aware that as long as I > am > >>>>> using Java 8 I might just re-introduce the stax-api bundle to > lib/endorsed, > >>>>> but what are the ideas for this on Java 9? > >>>>> > >>>>> Best regards > >>>>> Stephan > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> ------------------------ > >>>> Guillaume Nodet > >>>> > >>>> > >>> > >>> > >>> -- > >>> ------------------------ > >>> Guillaume Nodet > >>> > >>> > >> > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> > >> > > > > > > -- > > ------------------------ > > Guillaume Nodet > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > -- ------------------------ Guillaume Nodet
