karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Karaf 4.2.0 and endorsed libs
Date Wed, 28 Mar 2018 14:16:10 GMT


> On Mar 27, 2018, at 10:48 AM, Guillaume Nodet <gnodet@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?



Dan



> 
> 2018-03-23 14:30 GMT+01:00 Guillaume Nodet <gnodet@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 <gnodet@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 <gnodet@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.siano@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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message