cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: CXF issue with all CAPS fields (follow up and resolution)
Date Wed, 22 May 2013 00:55:13 GMT

-------------
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 <r.ouble@gmail.com> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message