Karaf 4.2.0 and endorsed libs

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Karaf 4.2.0 and endorsed libs

Siano, Stephan
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$LazyIterator.nextService(ServiceLoader.java:372)
                at java.util.ServiceLoader$LazyIterator.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.XMLInputFactory.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
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

Guillaume Nodet-2
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 <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

Guillaume Nodet-2
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

Guillaume Nodet-2
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

Guillaume Nodet-2
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>
>>>> 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
Reply | Threaded
Open this post in threaded view
|

RE: Karaf 4.2.0 and endorsed libs

Siano, Stephan
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:[hidden email]]
Sent: Dienstag, 27. März 2018 16:48
To: dev <[hidden email]>
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

cschneider
+1
Another milestone or rc1 release would be great to get some more people to
look into this.

Christian

2018-03-28 8:08 GMT+02:00 Siano, Stephan <[hidden email]>:

> 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:[hidden email]]
> Sent: Dienstag, 27. März 2018 16:48
> To: dev <[hidden email]>
> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> >> 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 <[hidden email]>:
> >>
> >>> 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 <[hidden email]>:
> >>>
> >>>> 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
>



--
--
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

jbonofre
We planned to do 4.2.0 before the end of this week.

I think M3 is not required, but why not RC1.

I think we can go with 4.2.0 and do a 4.2.1 pretty quickly if required.

Regards
JB

On 03/28/2018 09:32 AM, Christian Schneider wrote:

> +1
> Another milestone or rc1 release would be great to get some more people to
> look into this.
>
> Christian
>
> 2018-03-28 8:08 GMT+02:00 Siano, Stephan <[hidden email]>:
>
>> 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:[hidden email]]
>> Sent: Dienstag, 27. März 2018 16:48
>> To: dev <[hidden email]>
>> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>
>>>> 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 <[hidden email]>:
>>>>
>>>>> 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 <[hidden email]>:
>>>>>
>>>>>> 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
>>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

Daniel Kulp
In reply to this post by Guillaume Nodet-2


> On Mar 27, 2018, at 10:48 AM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>
>>>> 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 <[hidden email]>:
>>>>
>>>>> 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
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

jbonofre
It's also the SMX like specs.

Regards
JB

On 03/28/2018 04:16 PM, Daniel Kulp wrote:

>
>
>> On Mar 27, 2018, at 10:48 AM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>
>>>> 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 <[hidden email]>:
>>>>
>>>>> 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 <[hidden email]>:
>>>>>
>>>>>> 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
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf 4.2.0 and endorsed libs

Guillaume Nodet-2
In reply to this post by Daniel Kulp
2018-03-28 16:16 GMT+02:00 Daniel Kulp <[hidden email]>:

>
>
> > On Mar 27, 2018, at 10:48 AM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>:
> >
> >> 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 <[hidden email]>:
> >>
> >>> 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 <[hidden email]>:
> >>>
> >>>> 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 <[hidden email]>:
> >>>>
> >>>>> 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
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


--
------------------------
Guillaume Nodet