－－－－－－－－－－－－－ Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋
www.camelone.org : The open source integration conference: On 2013-5-22, at 上午1:02, Daniel Kulp wrote: > > >> Next steps: >> a) Do we want to up the JAXB version in the older 2.4 and 2.5 release >> trains to 2.2.6? > > 2.4 is unsupported so won't be updated. 2.5 is on 2.2.5 We likely could > update it. That said, I think we're missing OSGi bundles for 2.2.6 at this > point. Something for service mix. In Servicemix, there is already a jaxb-impl 2.2.6 bundle get released[1], I think we can upgrade cxf 2.6.x feature to use it. But there is no jaxb-impl 2.2.5 bundle, I can add it we still need it. [1]http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.jaxb-impl/2.2.6_1/ > > >> b) Can we add a testcase to the CXF regressions so that this kind of issue >> can be caught before and does not make it to a released version of CXF? >> [I would classify this as a show stopper - if CXF can't handle the case of >> fields it can not be taken seriously and can not be used in production >> environments] > > Feel free to write a unit test. However, keep in mind that it would have to > PASS on both Java6 (which would be using Jaxb 2.1.13) and Java7 (which would > be using 2.2.6). If the two of them behave differently, then the test would > need to reflect that. > > > Dan > > > > On May 21, 2013, at 10:36 AM, rouble <[email protected]> wrote: > >> Team, >> >> A while back I reported an issue where CXF 2.4.3 (JAXB 2.2.4) was unable to >> transport data objects that had fields names in all caps. So for instance >> something like: >> >> Widget { >> Foo FOO; >> Bar bar; >> } >> >> This is easily reproducible with a CXF 2.4.3 client talking to a CXF 2.4.3 >> server. Two defects were filed for this: >> https://issues.apache.org/jira/browse/CXF-4089 >> https://java.net/jira/browse/JAXB-880 >> >> At the time my analysis and the analysis of Daniel Kulp was that JAXB was >> generating a bad WSDL. We all came to this analysis because the WSDL was >> different from CXF 2.4.2 (JAXB 2.2.1). Now, it seems that was an incorrect >> analysis. >> >> After some tests on CXF 2.6.0 server (JAXB 2.2.6), which generates the >> exact same WSDL, I noticed it works fine with a CXF 2.6.0 client, but does >> not work fine with a CXF 2.4.3 client. >> >> This leads me to believe that the WSDL generated in CXF 2.6.0 is different >> but still correct, and the issue is actually on the client side when JAXB >> is unmarshaling the data object from the wire. However, I tested JAXB >> unmarshalling with 2.2.1 and 2.2.4 outside of CXF. So it seems to be an >> interaction issue between CXF and JAXB. >> >> Next steps: >> a) Do we want to up the JAXB version in the older 2.4 and 2.5 release >> trains to 2.2.6? >> b) Can we add a testcase to the CXF regressions so that this kind of issue >> can be caught before and does not make it to a released version of CXF? >> [I would classify this as a show stopper - if CXF can't handle the case of >> fields it can not be taken seriously and can not be used in production >> environments] >> >> Thanks >> Rouble > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
