You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by "Siano, Stephan" <st...@sap.com> on 2018/03/01 07:04:04 UTC

Karaf 4.2.0 and endorsed libs

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

Re: Karaf 4.2.0 and endorsed libs

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <st...@sap.com>:
> 
>> 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 <de...@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 <gn...@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 <gn...@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 <gn...@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 <st...@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
>>
> 
> 
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf 4.2.0 and endorsed libs

Posted by Christian Schneider <ch...@die-schneider.net>.
+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 <st...@sap.com>:

> 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 <de...@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 <gn...@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 <gn...@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 <gn...@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 <st...@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
>



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

Computer Scientist
http://www.adobe.com

RE: Karaf 4.2.0 and endorsed libs

Posted by "Siano, Stephan" <st...@sap.com>.
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 <de...@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 <gn...@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 <gn...@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 <gn...@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 <st...@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

Re: Karaf 4.2.0 and endorsed libs

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <gn...@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 <gn...@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 <gn...@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 <gn...@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 <st...@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
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf 4.2.0 and endorsed libs

Posted by Guillaume Nodet <gn...@apache.org>.
2018-03-28 16:16 GMT+02:00 Daniel Kulp <dk...@apache.org>:

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


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

Re: Karaf 4.2.0 and endorsed libs

Posted by Daniel Kulp <dk...@apache.org>.

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


Re: Karaf 4.2.0 and endorsed libs

Posted by Guillaume Nodet <gn...@apache.org>.
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 <gn...@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 <gn...@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 <gn...@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 <st...@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

Re: Karaf 4.2.0 and endorsed libs

Posted by Guillaume Nodet <gn...@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 <gn...@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 <gn...@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 <st...@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

Re: Karaf 4.2.0 and endorsed libs

Posted by Guillaume Nodet <gn...@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 <gn...@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 <st...@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

Re: Karaf 4.2.0 and endorsed libs

Posted by Guillaume Nodet <gn...@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 <st...@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