You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2012/01/02 18:15:14 UTC
Re: [PROPOSAL] Change the default jre.properties
On Wed, Dec 28, 2011 at 05:06, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday, December 27, 2011 3:22:48 PM Jean-Baptiste Onofré wrote:
>> Just a question, as you know CXF better than I:
>>
>> - why CXF can't use the packages provided by the JRE (assuming we use
>> JRE 1.6) ?
>
> Well, you did mention the JRE 1.6 thing... that is the first issue. CXF
> still supports Java5 (as does Karaf 2.2.x) and thus needs to provide a useful
> features.xml for Java5 folks. But that's a separate issue..... However,
> that IS the reason for having geronimo-annotation and geronimo-ws-metadata
> bundles. We could easily use the in JDK versions of these as they don't
> involve factories or implementations or anything like that.
We decided to drop JDK 5 in Karaf.
> SAAJ is the next spec to look at. Again, not part of Java5. However, the
> SAAJ implementations haven't changed in 3 years or so. Thus, using the
> version in the JDK is acceptable to me for now. However, this is a "factory"
> spec and thus the container should provide a way to load an additional
> implementations. Andreas and I HAVE talked about a new implementation based
> on his DDOM project that would allow deferred processing and such, but that
> project has been very slow in developing anything so I'm not worried about it
> now. There IS a strange issue with CXF and the SAAJ implementation in a
> certain version of WebSphere on AIX that I'm still not sure about where we did
> flip it out to use the Sun SAAJ impl, but that wasn't in Karaf/OSGi.
>
> The next spec to consider is StAX. CXF is OK (I think) with the in JDK
> version. (FYI: Camel 2.9.0 is not, more in a second) We don't test
> extensively with it as there are serious issues with the in JDK version. This
> falls into the area where every ENTERPRISE level person I've ever talked to
> has ALWAYS preferred performance and consistency and generally "works"
> compared to using JDK versions. The StAX implementation in the JDK is awful.
> Not only is it a LOT slower than WoodStox, it also is much harder to properly
> handle writing namespaces (CXF is OK I believe, but many other users of StAX
> don't know the details and thus don't handle it right.) The namespace issue
> is also different between the Sun JDK's, the Oracle JRocket based JDK's, and
> the IBM JDK's. However, the MAIN issue with the in-JDK version is that it's
> VERY VERY easy to write non-thread safe code. Most people don't realize that
> the StAX XMLInput/OutputFactory objects in the JDK are not thread safe. They
> are really the only commonly used "factories" in the XML spec that are not.
> Thus, people write code that works fine in the tests, but blows up when they
> scale up with strange errors and such. Just switching to woodstox (which has
> thread safe factories) fixes the issue. To prove my point, the Stax
> component submitted to Camel, reviewed by camel committers, committed, tested,
> etc... is NOT thread safe unless you use Woodstox due to the same issue.
> Again, putting woodstox in there not just provides enhanced performance and
> stability, it also prevents a whole range of programming problems and every
> enterprise customer I've ever talked to appreciates that. Basically, I'm OK
> using the "in JDK" API's as long as they can properly and easily load woodstox
> as the implementation.
>
> That leaves JAX-WS and JAXB. I'll start with JAX-WS. CXF is a certified
> JAX-WS 2.2 compliant JAX-WS implementation (except for the latest releases, we
> are working on fixing that). The code that is generated from the command
> line tools is JAX-WS 2.2 compliant. Thus, to use the generated code, you
> need to have the 2.2 API's. CXF does provide a "-fe jaxws21" flag to have
> it generate 2.1 compliant code, but for certification reasons and such, the
> default is 2.2. That said, when using Maven plugins, due to the endorse
> issues and such, you will get whatever version of JAX-WS API's found in the
> JDK. On java6, you will get 2.1 compliant code. On java7 or java5, you
> would get 2.2. The nice thing about the additions in 2.2 is that the API jar
> can be used with a 2.1 implementation. (new methods would throw
> UnsupportedOperationException). Thus, you can endorse the 2.2 API jar and
> still use the Java6 in-JDk 2.1 based version as long as you just use the 2.1
> provided methods. The main issue with JAX-WS is the "factory" issue. If I
> have CXF installed and I call "Endpoint.publish(...)" or "new
> MyService().getFooPort()", it should use CXF, not the in-JDK version. If the
> activator thing gnodet is working on can allow use of the system provided
> "API" packages (javax.xml.ws stuff) but have it find and load the CXF
> implementation, than I'm OK with that. That CAN be 2.1 on Java6 and 2.2 on
> Java5/7. However, there also would need to be a way on Java6 to have it
> update to 2.2 if really needed.
>
> Finally, that leaves JAXB. For 95% of the use cases, we can use the in-jdk
> version EXCEPT for the 2.1 vs 2.2 issue in the generated code. Again, we use
> the 2.2 xjc to generate code and thus it CAN generate code that will result in
> illegal annotation exceptions when run on 2.1. Again, the -fe jaxws21 flag
> works around that and the maven java6/7 things mentioned above come into play.
> The DynamicClient, however, requires the non-inJDK version as we have to call
> off to com.sun.xml.bind classes and such directly which have different
> packages in the JDK (.internal added) and it was way too much reflection
> needed to do it reflectively. CXF does have a few pathways where we try the
> ".internal" package names if the non-.internal versions aren't found
> specifically so it can work with the in-jdk version. It was just way too
> much to do for the DynamicClient however. (and the command line tools, but I
> assume we're not talking about running them in OSGi right now)
>
> However, the major issue I have with JAXB is the sheer number of bugs we run
> into with it. CXF users are constantly reporting bugs to us that, when
> debugged, turn out to be issues in JAXB. This last year has actually been
> good in that Oracle has actually fixed many of the bugs we reported, but ONLY
> in the 2.2 branch. Thus, to get the stable version with the bugs fixed, we
> need the 2.2. implementation. Unfortunately, you CANNOT use the 2.2
> implementation with the 2.1 API jar. The 2.2 implementation always looks for
> specific attributes on a couple annotations that only exist in 2.2 and will
> throw exceptions if the annotation is from 2.1 and doesn't contain them.
> However, I believe you can use a 2.2 API with the in -jdk 2.1 impl. Not 100%
> sure though.
>
> The other issue with JAXB related to the bugs is it's HARD to figure out what
> bugs you may encounter when using the in JDK version. They periodically
> update the in-jdk version with the JDK updates and various versions provide
> fixes, but also introduce new issues. I think JDK update 18 broke a few of
> CXF unit tests when using the in-JDK version. Update 23 fixed that. Update
> 27 introduced a never cleared thread local that causes jar locking (and thus
> memory leaks). I don't believe that has been fixed yet in any JDK other than
> the latest Java 7 (again, fixes go to 2.2 branch, rarely to 2.1). Also,
> flipping between the Sun/Oracle JDK (example, developer boxes) to IBM JDK's
> (example: deploy on AIX) can really cause differences in behavior.
>
Thx for those detailed explanations ... That really helps
understanding the problem.
>
> Unlike Guillaume, I've NEVER had an enterprise customer ask to use the in JDK
> versions. I've never seen anyone really request it, even on the lists here.
> In every case, they've valued performance and stability over the use of the
> in-JDK versions. By making CXF really prefer the "stable" versions, it not
> only provides a better experience for CXF users, but also reduces the support
> burden on the CXF lists as people are less likely to hit issues. That's
> important to me. If the Activator based stuff that Guillaume is working on
> can allow us to use the in-JDK "API" packages, but have them properly load
> OSGi based implementations, then that's a great start. If we can also
> provide the latest versions of those API's (so we can use the latest versions
> of those impls), I'd be happy.
>
I don't recall having that such a thing. Or that's not really what I
meant, so let me rephrase once again.
Imho Karaf is not a container dedicated to deploying Camel or CXF,
it's a general purpose OSGi container. So there are users that do use
Karaf and that don't care about CXF nor Camel. They may be very happy
with the JAXB version provided by the JRE and don't use Stax. I
don't really see why Karaf would have to provide its own Stax, JAXB,
SAAJ or JAXWS version for those users. Of course, they could still
use a container which would provide alternative implementations, but
it's all about being lightweight. I recall you once considered
ServiceMix being heavyweight, though the minimal distribution is now
only 10 Mb, where everything (cxf, camel, activemq, jbi) is ready to
be installed. It's the same idea as TSF iirc.
I hope in the future, other Apache projects may use Karaf as their
runtime. DIrectory is an example and afaik they don't really care
about the speed of the JRE provided Stax implementation. There's imho
no need to include stuff in Karaf that isnt used by Karaf and may not
be used by users either. That sounds like a custom distribution to
me.
>
> Anyway, I'm technically on vacation. My wife is giving me dirty looks for
> spending an hour doing work. I hope this helps explain things a bit. :-)
It does.
At the end I think we should provide a custom distribution (I still
think ServiceMix minimal could be a good candidate, but even it could
be yet another distribution in Karaf too, or even in CXF) that would
provide a clean and configured environment for CXF, with the needed
specs and implementations.
I'll try to create a karaf branch at github to experiment with the new
specs behavior, but what I had a few weeks ago was promising. But I'd
like that to work well with OBR too.
>
> Dan
>
>
>
>>
>> Regards
>> JB
>>
>> On 12/27/2011 03:18 PM, Christian Schneider wrote:
>> > Hi JB,
>> >
>> > I think that should not be a big problem.
>> >
>> > We currently only support three different runtimes 1.5, 1.6 and 1.7. So
>> > it should not be a lot of work to provide features for them.
>> > We could also support the jre version as a kind of switch for feature
>> > files. So you can define bundles that will only be installed for certain
>> > jre versions.
>> > A bit like in maven. So then one feature would be fine for all 3
>> > versions.
>> >
>> > Christian
>> >
>> > Am 27.12.2011 13:42, schrieb Jean-Baptiste Onofré:
>> >> As discussed on IRC, my concern with your solution is about multiple
>> >> JRE support: different versions, different providers (IBM, Sun/Oracle)
>> >> etc.
>> >>
>> >> It's really painful to create fragments bundle per JRE, and know which
>> >> one to deploy.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 12/26/2011 09:09 PM, Christian Schneider wrote:
>> >>> I am +1 for not exporting the packages by default in the system
>> >>> bundle.
>> >>>
>> >>> I also have an idea how we could create an environment for people
>> >>> who do not want the improved bundles.
>> >>>
>> >>> I propose that we provide two (sets of) features:
>> >>>
>> >>> 1. jaxb, stax, ... from jre
>> >>> These are just fragment bundles to the system bundle that export the
>> >>> packages. So by installing these bundles
>> >>> you get the current behaviour of karaf
>> >>>
>> >>> 2. improved jaxb, stax, .. like used for servicemix, cxf, camel
>> >>> These will make cxf and camel behave like expected
>> >>>
>> >>> The reason why I prefer this aproach over the current setup of
>> >>> simply
>> >>> exporting the packages from the system bundle is that it makes
>> >>> installing cxf and camel much easier and at the same time also
>> >>> allows
>> >>> people to use "pure OSGi" like Guillaume wrote.
>> >>>
>> >>> Christian
>> >>>
>> >>> Am 26.12.2011 16:04, schrieb Jean-Baptiste Onofré:
>> >>>> Hi all,
>> >>>>
>> >>>> We have currently an issue in Camel and CXF with the default
>> >>>> jre.properties and some exported packages (like JAXB, etc).
>> >>>>
>> >>>> Currently, by default, the jre.properties exports all packages
>> >>>> from
>> >>>> the JRE.
>> >>>>
>> >>>> I would like to propose a new approach:
>> >>>> 1/ remove packages with problem by default from the jre.properties
>> >>>> 2/ add a set of Karaf features (in bootFeatures by default) to
>> >>>> install
>> >>>> bundles providing the packages (JAXB, etc)
>> >>>>
>> >>>> It's a quick workaround for next Karaf 2.2.6 and Karaf 3.0.
>> >>>>
>> >>>> We can find a more elegant solution. I have some solutions in
>> >>>> mind:
>> >>>> - new properties in the jre.properties to define an "override"
>> >>>> flag
>> >>>> - add a KARAF-INF/* files to define some behaviors (like
>> >>>> overriding
>> >>>> system packages)
>> >>>>
>> >>>> Feel free to propose your ideas for this problem.
>> >>>>
>> >>>> Please:
>> >>>> [ ] +1 to remove the packages from the jre.properties and provide
>> >>>> a
>> >>>> set of Spec/API features in Karaf
>> >>>> [ ] 0
>> >>>> [ ] -1 for that (please provide arguments)
>> >>>> Ideas (if you have ;)):
>> >>>>
>> >>>> Thanks
>> >>>> Regards
>> >>>> JB
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [PROPOSAL] Change the default jre.properties
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,
thanks a bunch, it looks great.
I will make a try later today.
Regards
JB
On 01/04/2012 10:58 AM, Guillaume Nodet wrote:
> I've pushed some changed to servicemix specs and create a github
> branch of karaf containing a new distribution that embeds those specs:
> https://github.com/gnodet/karaf/tree/enhanced
>
> I can then do the following:
>
> ((((($.context bundle 0) loadClass "javax.xml.stream.XMLInputFactory")
> getMethod newInstance) invoke null) getClass) getName
> bundle:install mvn:org.codehaus.woodstox/stax2-api/3.1.1
> bundle:install -s mvn:org.codehaus.woodstox/woodstox-core-asl/4.1.1
> ((((($.context bundle 0) loadClass "javax.xml.stream.XMLInputFactory")
> getMethod newInstance) invoke null) getClass) getName
>
> And you should see that the first call was using the JRE built in stax
> impl and the second one was using woodstox.
>
> If you want to see what happens with the spec, you can add
> org.apache.servicemix.debug=true property in etc/system.properties
> before starting.
>
>
> On Mon, Jan 2, 2012 at 18:15, Guillaume Nodet<gn...@gmail.com> wrote:
>> On Wed, Dec 28, 2011 at 05:06, Daniel Kulp<dk...@apache.org> wrote:
>>> On Tuesday, December 27, 2011 3:22:48 PM Jean-Baptiste Onofré wrote:
>>>> Just a question, as you know CXF better than I:
>>>>
>>>> - why CXF can't use the packages provided by the JRE (assuming we use
>>>> JRE 1.6) ?
>>>
>>> Well, you did mention the JRE 1.6 thing... that is the first issue. CXF
>>> still supports Java5 (as does Karaf 2.2.x) and thus needs to provide a useful
>>> features.xml for Java5 folks. But that's a separate issue..... However,
>>> that IS the reason for having geronimo-annotation and geronimo-ws-metadata
>>> bundles. We could easily use the in JDK versions of these as they don't
>>> involve factories or implementations or anything like that.
>>
>> We decided to drop JDK 5 in Karaf.
>>
>>> SAAJ is the next spec to look at. Again, not part of Java5. However, the
>>> SAAJ implementations haven't changed in 3 years or so. Thus, using the
>>> version in the JDK is acceptable to me for now. However, this is a "factory"
>>> spec and thus the container should provide a way to load an additional
>>> implementations. Andreas and I HAVE talked about a new implementation based
>>> on his DDOM project that would allow deferred processing and such, but that
>>> project has been very slow in developing anything so I'm not worried about it
>>> now. There IS a strange issue with CXF and the SAAJ implementation in a
>>> certain version of WebSphere on AIX that I'm still not sure about where we did
>>> flip it out to use the Sun SAAJ impl, but that wasn't in Karaf/OSGi.
>>>
>>> The next spec to consider is StAX. CXF is OK (I think) with the in JDK
>>> version. (FYI: Camel 2.9.0 is not, more in a second) We don't test
>>> extensively with it as there are serious issues with the in JDK version. This
>>> falls into the area where every ENTERPRISE level person I've ever talked to
>>> has ALWAYS preferred performance and consistency and generally "works"
>>> compared to using JDK versions. The StAX implementation in the JDK is awful.
>>> Not only is it a LOT slower than WoodStox, it also is much harder to properly
>>> handle writing namespaces (CXF is OK I believe, but many other users of StAX
>>> don't know the details and thus don't handle it right.) The namespace issue
>>> is also different between the Sun JDK's, the Oracle JRocket based JDK's, and
>>> the IBM JDK's. However, the MAIN issue with the in-JDK version is that it's
>>> VERY VERY easy to write non-thread safe code. Most people don't realize that
>>> the StAX XMLInput/OutputFactory objects in the JDK are not thread safe. They
>>> are really the only commonly used "factories" in the XML spec that are not.
>>> Thus, people write code that works fine in the tests, but blows up when they
>>> scale up with strange errors and such. Just switching to woodstox (which has
>>> thread safe factories) fixes the issue. To prove my point, the Stax
>>> component submitted to Camel, reviewed by camel committers, committed, tested,
>>> etc... is NOT thread safe unless you use Woodstox due to the same issue.
>>> Again, putting woodstox in there not just provides enhanced performance and
>>> stability, it also prevents a whole range of programming problems and every
>>> enterprise customer I've ever talked to appreciates that. Basically, I'm OK
>>> using the "in JDK" API's as long as they can properly and easily load woodstox
>>> as the implementation.
>>>
>>> That leaves JAX-WS and JAXB. I'll start with JAX-WS. CXF is a certified
>>> JAX-WS 2.2 compliant JAX-WS implementation (except for the latest releases, we
>>> are working on fixing that). The code that is generated from the command
>>> line tools is JAX-WS 2.2 compliant. Thus, to use the generated code, you
>>> need to have the 2.2 API's. CXF does provide a "-fe jaxws21" flag to have
>>> it generate 2.1 compliant code, but for certification reasons and such, the
>>> default is 2.2. That said, when using Maven plugins, due to the endorse
>>> issues and such, you will get whatever version of JAX-WS API's found in the
>>> JDK. On java6, you will get 2.1 compliant code. On java7 or java5, you
>>> would get 2.2. The nice thing about the additions in 2.2 is that the API jar
>>> can be used with a 2.1 implementation. (new methods would throw
>>> UnsupportedOperationException). Thus, you can endorse the 2.2 API jar and
>>> still use the Java6 in-JDk 2.1 based version as long as you just use the 2.1
>>> provided methods. The main issue with JAX-WS is the "factory" issue. If I
>>> have CXF installed and I call "Endpoint.publish(...)" or "new
>>> MyService().getFooPort()", it should use CXF, not the in-JDK version. If the
>>> activator thing gnodet is working on can allow use of the system provided
>>> "API" packages (javax.xml.ws stuff) but have it find and load the CXF
>>> implementation, than I'm OK with that. That CAN be 2.1 on Java6 and 2.2 on
>>> Java5/7. However, there also would need to be a way on Java6 to have it
>>> update to 2.2 if really needed.
>>>
>>> Finally, that leaves JAXB. For 95% of the use cases, we can use the in-jdk
>>> version EXCEPT for the 2.1 vs 2.2 issue in the generated code. Again, we use
>>> the 2.2 xjc to generate code and thus it CAN generate code that will result in
>>> illegal annotation exceptions when run on 2.1. Again, the -fe jaxws21 flag
>>> works around that and the maven java6/7 things mentioned above come into play.
>>> The DynamicClient, however, requires the non-inJDK version as we have to call
>>> off to com.sun.xml.bind classes and such directly which have different
>>> packages in the JDK (.internal added) and it was way too much reflection
>>> needed to do it reflectively. CXF does have a few pathways where we try the
>>> ".internal" package names if the non-.internal versions aren't found
>>> specifically so it can work with the in-jdk version. It was just way too
>>> much to do for the DynamicClient however. (and the command line tools, but I
>>> assume we're not talking about running them in OSGi right now)
>>>
>>> However, the major issue I have with JAXB is the sheer number of bugs we run
>>> into with it. CXF users are constantly reporting bugs to us that, when
>>> debugged, turn out to be issues in JAXB. This last year has actually been
>>> good in that Oracle has actually fixed many of the bugs we reported, but ONLY
>>> in the 2.2 branch. Thus, to get the stable version with the bugs fixed, we
>>> need the 2.2. implementation. Unfortunately, you CANNOT use the 2.2
>>> implementation with the 2.1 API jar. The 2.2 implementation always looks for
>>> specific attributes on a couple annotations that only exist in 2.2 and will
>>> throw exceptions if the annotation is from 2.1 and doesn't contain them.
>>> However, I believe you can use a 2.2 API with the in -jdk 2.1 impl. Not 100%
>>> sure though.
>>>
>>> The other issue with JAXB related to the bugs is it's HARD to figure out what
>>> bugs you may encounter when using the in JDK version. They periodically
>>> update the in-jdk version with the JDK updates and various versions provide
>>> fixes, but also introduce new issues. I think JDK update 18 broke a few of
>>> CXF unit tests when using the in-JDK version. Update 23 fixed that. Update
>>> 27 introduced a never cleared thread local that causes jar locking (and thus
>>> memory leaks). I don't believe that has been fixed yet in any JDK other than
>>> the latest Java 7 (again, fixes go to 2.2 branch, rarely to 2.1). Also,
>>> flipping between the Sun/Oracle JDK (example, developer boxes) to IBM JDK's
>>> (example: deploy on AIX) can really cause differences in behavior.
>>>
>>
>> Thx for those detailed explanations ... That really helps
>> understanding the problem.
>>
>>>
>>> Unlike Guillaume, I've NEVER had an enterprise customer ask to use the in JDK
>>> versions. I've never seen anyone really request it, even on the lists here.
>>> In every case, they've valued performance and stability over the use of the
>>> in-JDK versions. By making CXF really prefer the "stable" versions, it not
>>> only provides a better experience for CXF users, but also reduces the support
>>> burden on the CXF lists as people are less likely to hit issues. That's
>>> important to me. If the Activator based stuff that Guillaume is working on
>>> can allow us to use the in-JDK "API" packages, but have them properly load
>>> OSGi based implementations, then that's a great start. If we can also
>>> provide the latest versions of those API's (so we can use the latest versions
>>> of those impls), I'd be happy.
>>>
>>
>> I don't recall having that such a thing. Or that's not really what I
>> meant, so let me rephrase once again.
>>
>> Imho Karaf is not a container dedicated to deploying Camel or CXF,
>> it's a general purpose OSGi container. So there are users that do use
>> Karaf and that don't care about CXF nor Camel. They may be very happy
>> with the JAXB version provided by the JRE and don't use Stax. I
>> don't really see why Karaf would have to provide its own Stax, JAXB,
>> SAAJ or JAXWS version for those users. Of course, they could still
>> use a container which would provide alternative implementations, but
>> it's all about being lightweight. I recall you once considered
>> ServiceMix being heavyweight, though the minimal distribution is now
>> only 10 Mb, where everything (cxf, camel, activemq, jbi) is ready to
>> be installed. It's the same idea as TSF iirc.
>>
>> I hope in the future, other Apache projects may use Karaf as their
>> runtime. DIrectory is an example and afaik they don't really care
>> about the speed of the JRE provided Stax implementation. There's imho
>> no need to include stuff in Karaf that isnt used by Karaf and may not
>> be used by users either. That sounds like a custom distribution to
>> me.
>>
>>>
>>> Anyway, I'm technically on vacation. My wife is giving me dirty looks for
>>> spending an hour doing work. I hope this helps explain things a bit. :-)
>>
>> It does.
>>
>> At the end I think we should provide a custom distribution (I still
>> think ServiceMix minimal could be a good candidate, but even it could
>> be yet another distribution in Karaf too, or even in CXF) that would
>> provide a clean and configured environment for CXF, with the needed
>> specs and implementations.
>>
>> I'll try to create a karaf branch at github to experiment with the new
>> specs behavior, but what I had a few weeks ago was promising. But I'd
>> like that to work well with OBR too.
>>
>>>
>>> Dan
>>>
>>>
>>>
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 12/27/2011 03:18 PM, Christian Schneider wrote:
>>>>> Hi JB,
>>>>>
>>>>> I think that should not be a big problem.
>>>>>
>>>>> We currently only support three different runtimes 1.5, 1.6 and 1.7. So
>>>>> it should not be a lot of work to provide features for them.
>>>>> We could also support the jre version as a kind of switch for feature
>>>>> files. So you can define bundles that will only be installed for certain
>>>>> jre versions.
>>>>> A bit like in maven. So then one feature would be fine for all 3
>>>>> versions.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 27.12.2011 13:42, schrieb Jean-Baptiste Onofré:
>>>>>> As discussed on IRC, my concern with your solution is about multiple
>>>>>> JRE support: different versions, different providers (IBM, Sun/Oracle)
>>>>>> etc.
>>>>>>
>>>>>> It's really painful to create fragments bundle per JRE, and know which
>>>>>> one to deploy.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 12/26/2011 09:09 PM, Christian Schneider wrote:
>>>>>>> I am +1 for not exporting the packages by default in the system
>>>>>>> bundle.
>>>>>>>
>>>>>>> I also have an idea how we could create an environment for people
>>>>>>> who do not want the improved bundles.
>>>>>>>
>>>>>>> I propose that we provide two (sets of) features:
>>>>>>>
>>>>>>> 1. jaxb, stax, ... from jre
>>>>>>> These are just fragment bundles to the system bundle that export the
>>>>>>> packages. So by installing these bundles
>>>>>>> you get the current behaviour of karaf
>>>>>>>
>>>>>>> 2. improved jaxb, stax, .. like used for servicemix, cxf, camel
>>>>>>> These will make cxf and camel behave like expected
>>>>>>>
>>>>>>> The reason why I prefer this aproach over the current setup of
>>>>>>> simply
>>>>>>> exporting the packages from the system bundle is that it makes
>>>>>>> installing cxf and camel much easier and at the same time also
>>>>>>> allows
>>>>>>> people to use "pure OSGi" like Guillaume wrote.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> Am 26.12.2011 16:04, schrieb Jean-Baptiste Onofré:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> We have currently an issue in Camel and CXF with the default
>>>>>>>> jre.properties and some exported packages (like JAXB, etc).
>>>>>>>>
>>>>>>>> Currently, by default, the jre.properties exports all packages
>>>>>>>> from
>>>>>>>> the JRE.
>>>>>>>>
>>>>>>>> I would like to propose a new approach:
>>>>>>>> 1/ remove packages with problem by default from the jre.properties
>>>>>>>> 2/ add a set of Karaf features (in bootFeatures by default) to
>>>>>>>> install
>>>>>>>> bundles providing the packages (JAXB, etc)
>>>>>>>>
>>>>>>>> It's a quick workaround for next Karaf 2.2.6 and Karaf 3.0.
>>>>>>>>
>>>>>>>> We can find a more elegant solution. I have some solutions in
>>>>>>>> mind:
>>>>>>>> - new properties in the jre.properties to define an "override"
>>>>>>>> flag
>>>>>>>> - add a KARAF-INF/* files to define some behaviors (like
>>>>>>>> overriding
>>>>>>>> system packages)
>>>>>>>>
>>>>>>>> Feel free to propose your ideas for this problem.
>>>>>>>>
>>>>>>>> Please:
>>>>>>>> [ ] +1 to remove the packages from the jre.properties and provide
>>>>>>>> a
>>>>>>>> set of Spec/API features in Karaf
>>>>>>>> [ ] 0
>>>>>>>> [ ] -1 for that (please provide arguments)
>>>>>>>> Ideas (if you have ;)):
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Regards
>>>>>>>> JB
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Change the default jre.properties
Posted by Christian Schneider <ch...@die-schneider.net>.
Sounds great. To what specs is that applicable? Can we solve all the
changes necessary for cxf with a solution like that?
Christian
Am 04.01.2012 10:58, schrieb Guillaume Nodet:
> I've pushed some changed to servicemix specs and create a github
> branch of karaf containing a new distribution that embeds those specs:
> https://github.com/gnodet/karaf/tree/enhanced
>
> I can then do the following:
>
> ((((($.context bundle 0) loadClass "javax.xml.stream.XMLInputFactory")
> getMethod newInstance) invoke null) getClass) getName
> bundle:install mvn:org.codehaus.woodstox/stax2-api/3.1.1
> bundle:install -s mvn:org.codehaus.woodstox/woodstox-core-asl/4.1.1
> ((((($.context bundle 0) loadClass "javax.xml.stream.XMLInputFactory")
> getMethod newInstance) invoke null) getClass) getName
>
> And you should see that the first call was using the JRE built in stax
> impl and the second one was using woodstox.
>
> If you want to see what happens with the spec, you can add
> org.apache.servicemix.debug=true property in etc/system.properties
> before starting.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Change the default jre.properties
Posted by Guillaume Nodet <gn...@gmail.com>.
I've pushed some changed to servicemix specs and create a github
branch of karaf containing a new distribution that embeds those specs:
https://github.com/gnodet/karaf/tree/enhanced
I can then do the following:
((((($.context bundle 0) loadClass "javax.xml.stream.XMLInputFactory")
getMethod newInstance) invoke null) getClass) getName
bundle:install mvn:org.codehaus.woodstox/stax2-api/3.1.1
bundle:install -s mvn:org.codehaus.woodstox/woodstox-core-asl/4.1.1
((((($.context bundle 0) loadClass "javax.xml.stream.XMLInputFactory")
getMethod newInstance) invoke null) getClass) getName
And you should see that the first call was using the JRE built in stax
impl and the second one was using woodstox.
If you want to see what happens with the spec, you can add
org.apache.servicemix.debug=true property in etc/system.properties
before starting.
On Mon, Jan 2, 2012 at 18:15, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Dec 28, 2011 at 05:06, Daniel Kulp <dk...@apache.org> wrote:
>> On Tuesday, December 27, 2011 3:22:48 PM Jean-Baptiste Onofré wrote:
>>> Just a question, as you know CXF better than I:
>>>
>>> - why CXF can't use the packages provided by the JRE (assuming we use
>>> JRE 1.6) ?
>>
>> Well, you did mention the JRE 1.6 thing... that is the first issue. CXF
>> still supports Java5 (as does Karaf 2.2.x) and thus needs to provide a useful
>> features.xml for Java5 folks. But that's a separate issue..... However,
>> that IS the reason for having geronimo-annotation and geronimo-ws-metadata
>> bundles. We could easily use the in JDK versions of these as they don't
>> involve factories or implementations or anything like that.
>
> We decided to drop JDK 5 in Karaf.
>
>> SAAJ is the next spec to look at. Again, not part of Java5. However, the
>> SAAJ implementations haven't changed in 3 years or so. Thus, using the
>> version in the JDK is acceptable to me for now. However, this is a "factory"
>> spec and thus the container should provide a way to load an additional
>> implementations. Andreas and I HAVE talked about a new implementation based
>> on his DDOM project that would allow deferred processing and such, but that
>> project has been very slow in developing anything so I'm not worried about it
>> now. There IS a strange issue with CXF and the SAAJ implementation in a
>> certain version of WebSphere on AIX that I'm still not sure about where we did
>> flip it out to use the Sun SAAJ impl, but that wasn't in Karaf/OSGi.
>>
>> The next spec to consider is StAX. CXF is OK (I think) with the in JDK
>> version. (FYI: Camel 2.9.0 is not, more in a second) We don't test
>> extensively with it as there are serious issues with the in JDK version. This
>> falls into the area where every ENTERPRISE level person I've ever talked to
>> has ALWAYS preferred performance and consistency and generally "works"
>> compared to using JDK versions. The StAX implementation in the JDK is awful.
>> Not only is it a LOT slower than WoodStox, it also is much harder to properly
>> handle writing namespaces (CXF is OK I believe, but many other users of StAX
>> don't know the details and thus don't handle it right.) The namespace issue
>> is also different between the Sun JDK's, the Oracle JRocket based JDK's, and
>> the IBM JDK's. However, the MAIN issue with the in-JDK version is that it's
>> VERY VERY easy to write non-thread safe code. Most people don't realize that
>> the StAX XMLInput/OutputFactory objects in the JDK are not thread safe. They
>> are really the only commonly used "factories" in the XML spec that are not.
>> Thus, people write code that works fine in the tests, but blows up when they
>> scale up with strange errors and such. Just switching to woodstox (which has
>> thread safe factories) fixes the issue. To prove my point, the Stax
>> component submitted to Camel, reviewed by camel committers, committed, tested,
>> etc... is NOT thread safe unless you use Woodstox due to the same issue.
>> Again, putting woodstox in there not just provides enhanced performance and
>> stability, it also prevents a whole range of programming problems and every
>> enterprise customer I've ever talked to appreciates that. Basically, I'm OK
>> using the "in JDK" API's as long as they can properly and easily load woodstox
>> as the implementation.
>>
>> That leaves JAX-WS and JAXB. I'll start with JAX-WS. CXF is a certified
>> JAX-WS 2.2 compliant JAX-WS implementation (except for the latest releases, we
>> are working on fixing that). The code that is generated from the command
>> line tools is JAX-WS 2.2 compliant. Thus, to use the generated code, you
>> need to have the 2.2 API's. CXF does provide a "-fe jaxws21" flag to have
>> it generate 2.1 compliant code, but for certification reasons and such, the
>> default is 2.2. That said, when using Maven plugins, due to the endorse
>> issues and such, you will get whatever version of JAX-WS API's found in the
>> JDK. On java6, you will get 2.1 compliant code. On java7 or java5, you
>> would get 2.2. The nice thing about the additions in 2.2 is that the API jar
>> can be used with a 2.1 implementation. (new methods would throw
>> UnsupportedOperationException). Thus, you can endorse the 2.2 API jar and
>> still use the Java6 in-JDk 2.1 based version as long as you just use the 2.1
>> provided methods. The main issue with JAX-WS is the "factory" issue. If I
>> have CXF installed and I call "Endpoint.publish(...)" or "new
>> MyService().getFooPort()", it should use CXF, not the in-JDK version. If the
>> activator thing gnodet is working on can allow use of the system provided
>> "API" packages (javax.xml.ws stuff) but have it find and load the CXF
>> implementation, than I'm OK with that. That CAN be 2.1 on Java6 and 2.2 on
>> Java5/7. However, there also would need to be a way on Java6 to have it
>> update to 2.2 if really needed.
>>
>> Finally, that leaves JAXB. For 95% of the use cases, we can use the in-jdk
>> version EXCEPT for the 2.1 vs 2.2 issue in the generated code. Again, we use
>> the 2.2 xjc to generate code and thus it CAN generate code that will result in
>> illegal annotation exceptions when run on 2.1. Again, the -fe jaxws21 flag
>> works around that and the maven java6/7 things mentioned above come into play.
>> The DynamicClient, however, requires the non-inJDK version as we have to call
>> off to com.sun.xml.bind classes and such directly which have different
>> packages in the JDK (.internal added) and it was way too much reflection
>> needed to do it reflectively. CXF does have a few pathways where we try the
>> ".internal" package names if the non-.internal versions aren't found
>> specifically so it can work with the in-jdk version. It was just way too
>> much to do for the DynamicClient however. (and the command line tools, but I
>> assume we're not talking about running them in OSGi right now)
>>
>> However, the major issue I have with JAXB is the sheer number of bugs we run
>> into with it. CXF users are constantly reporting bugs to us that, when
>> debugged, turn out to be issues in JAXB. This last year has actually been
>> good in that Oracle has actually fixed many of the bugs we reported, but ONLY
>> in the 2.2 branch. Thus, to get the stable version with the bugs fixed, we
>> need the 2.2. implementation. Unfortunately, you CANNOT use the 2.2
>> implementation with the 2.1 API jar. The 2.2 implementation always looks for
>> specific attributes on a couple annotations that only exist in 2.2 and will
>> throw exceptions if the annotation is from 2.1 and doesn't contain them.
>> However, I believe you can use a 2.2 API with the in -jdk 2.1 impl. Not 100%
>> sure though.
>>
>> The other issue with JAXB related to the bugs is it's HARD to figure out what
>> bugs you may encounter when using the in JDK version. They periodically
>> update the in-jdk version with the JDK updates and various versions provide
>> fixes, but also introduce new issues. I think JDK update 18 broke a few of
>> CXF unit tests when using the in-JDK version. Update 23 fixed that. Update
>> 27 introduced a never cleared thread local that causes jar locking (and thus
>> memory leaks). I don't believe that has been fixed yet in any JDK other than
>> the latest Java 7 (again, fixes go to 2.2 branch, rarely to 2.1). Also,
>> flipping between the Sun/Oracle JDK (example, developer boxes) to IBM JDK's
>> (example: deploy on AIX) can really cause differences in behavior.
>>
>
> Thx for those detailed explanations ... That really helps
> understanding the problem.
>
>>
>> Unlike Guillaume, I've NEVER had an enterprise customer ask to use the in JDK
>> versions. I've never seen anyone really request it, even on the lists here.
>> In every case, they've valued performance and stability over the use of the
>> in-JDK versions. By making CXF really prefer the "stable" versions, it not
>> only provides a better experience for CXF users, but also reduces the support
>> burden on the CXF lists as people are less likely to hit issues. That's
>> important to me. If the Activator based stuff that Guillaume is working on
>> can allow us to use the in-JDK "API" packages, but have them properly load
>> OSGi based implementations, then that's a great start. If we can also
>> provide the latest versions of those API's (so we can use the latest versions
>> of those impls), I'd be happy.
>>
>
> I don't recall having that such a thing. Or that's not really what I
> meant, so let me rephrase once again.
>
> Imho Karaf is not a container dedicated to deploying Camel or CXF,
> it's a general purpose OSGi container. So there are users that do use
> Karaf and that don't care about CXF nor Camel. They may be very happy
> with the JAXB version provided by the JRE and don't use Stax. I
> don't really see why Karaf would have to provide its own Stax, JAXB,
> SAAJ or JAXWS version for those users. Of course, they could still
> use a container which would provide alternative implementations, but
> it's all about being lightweight. I recall you once considered
> ServiceMix being heavyweight, though the minimal distribution is now
> only 10 Mb, where everything (cxf, camel, activemq, jbi) is ready to
> be installed. It's the same idea as TSF iirc.
>
> I hope in the future, other Apache projects may use Karaf as their
> runtime. DIrectory is an example and afaik they don't really care
> about the speed of the JRE provided Stax implementation. There's imho
> no need to include stuff in Karaf that isnt used by Karaf and may not
> be used by users either. That sounds like a custom distribution to
> me.
>
>>
>> Anyway, I'm technically on vacation. My wife is giving me dirty looks for
>> spending an hour doing work. I hope this helps explain things a bit. :-)
>
> It does.
>
> At the end I think we should provide a custom distribution (I still
> think ServiceMix minimal could be a good candidate, but even it could
> be yet another distribution in Karaf too, or even in CXF) that would
> provide a clean and configured environment for CXF, with the needed
> specs and implementations.
>
> I'll try to create a karaf branch at github to experiment with the new
> specs behavior, but what I had a few weeks ago was promising. But I'd
> like that to work well with OBR too.
>
>>
>> Dan
>>
>>
>>
>>>
>>> Regards
>>> JB
>>>
>>> On 12/27/2011 03:18 PM, Christian Schneider wrote:
>>> > Hi JB,
>>> >
>>> > I think that should not be a big problem.
>>> >
>>> > We currently only support three different runtimes 1.5, 1.6 and 1.7. So
>>> > it should not be a lot of work to provide features for them.
>>> > We could also support the jre version as a kind of switch for feature
>>> > files. So you can define bundles that will only be installed for certain
>>> > jre versions.
>>> > A bit like in maven. So then one feature would be fine for all 3
>>> > versions.
>>> >
>>> > Christian
>>> >
>>> > Am 27.12.2011 13:42, schrieb Jean-Baptiste Onofré:
>>> >> As discussed on IRC, my concern with your solution is about multiple
>>> >> JRE support: different versions, different providers (IBM, Sun/Oracle)
>>> >> etc.
>>> >>
>>> >> It's really painful to create fragments bundle per JRE, and know which
>>> >> one to deploy.
>>> >>
>>> >> Regards
>>> >> JB
>>> >>
>>> >> On 12/26/2011 09:09 PM, Christian Schneider wrote:
>>> >>> I am +1 for not exporting the packages by default in the system
>>> >>> bundle.
>>> >>>
>>> >>> I also have an idea how we could create an environment for people
>>> >>> who do not want the improved bundles.
>>> >>>
>>> >>> I propose that we provide two (sets of) features:
>>> >>>
>>> >>> 1. jaxb, stax, ... from jre
>>> >>> These are just fragment bundles to the system bundle that export the
>>> >>> packages. So by installing these bundles
>>> >>> you get the current behaviour of karaf
>>> >>>
>>> >>> 2. improved jaxb, stax, .. like used for servicemix, cxf, camel
>>> >>> These will make cxf and camel behave like expected
>>> >>>
>>> >>> The reason why I prefer this aproach over the current setup of
>>> >>> simply
>>> >>> exporting the packages from the system bundle is that it makes
>>> >>> installing cxf and camel much easier and at the same time also
>>> >>> allows
>>> >>> people to use "pure OSGi" like Guillaume wrote.
>>> >>>
>>> >>> Christian
>>> >>>
>>> >>> Am 26.12.2011 16:04, schrieb Jean-Baptiste Onofré:
>>> >>>> Hi all,
>>> >>>>
>>> >>>> We have currently an issue in Camel and CXF with the default
>>> >>>> jre.properties and some exported packages (like JAXB, etc).
>>> >>>>
>>> >>>> Currently, by default, the jre.properties exports all packages
>>> >>>> from
>>> >>>> the JRE.
>>> >>>>
>>> >>>> I would like to propose a new approach:
>>> >>>> 1/ remove packages with problem by default from the jre.properties
>>> >>>> 2/ add a set of Karaf features (in bootFeatures by default) to
>>> >>>> install
>>> >>>> bundles providing the packages (JAXB, etc)
>>> >>>>
>>> >>>> It's a quick workaround for next Karaf 2.2.6 and Karaf 3.0.
>>> >>>>
>>> >>>> We can find a more elegant solution. I have some solutions in
>>> >>>> mind:
>>> >>>> - new properties in the jre.properties to define an "override"
>>> >>>> flag
>>> >>>> - add a KARAF-INF/* files to define some behaviors (like
>>> >>>> overriding
>>> >>>> system packages)
>>> >>>>
>>> >>>> Feel free to propose your ideas for this problem.
>>> >>>>
>>> >>>> Please:
>>> >>>> [ ] +1 to remove the packages from the jre.properties and provide
>>> >>>> a
>>> >>>> set of Spec/API features in Karaf
>>> >>>> [ ] 0
>>> >>>> [ ] -1 for that (please provide arguments)
>>> >>>> Ideas (if you have ;)):
>>> >>>>
>>> >>>> Thanks
>>> >>>> Regards
>>> >>>> JB
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com