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. 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. 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. 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. :-) 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
