On Wed, Dec 28, 2011 at 05:06, Daniel Kulp<[email protected]> 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
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
