karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siano, Stephan" <stephan.si...@sap.com>
Subject RE: Karaf 4.2.0 and endorsed libs
Date Wed, 28 Mar 2018 06:08:49 GMT
Hi,

That looks really cool!

Wouldn't it a good idea to have another 4.2.0 milestone release with this (and pax-web 7.0.0
support which was also merged yesterday)? Or will we see a 4.2.0 GA release soon?

Best regards
Stephan

-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@apache.org] 
Sent: Dienstag, 27. März 2018 16:48
To: dev <dev@karaf.apache.org>
Subject: Re: Karaf 4.2.0 and endorsed libs

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

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
Mime
View raw message