karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [PROPOSAL] Change the default jre.properties
Date Wed, 04 Jan 2012 13:02:01 GMT
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<gnodet@gmail.com>  wrote:
>> On Wed, Dec 28, 2011 at 05:06, Daniel Kulp<dkulp@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

Mime
View raw message