You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by rouble <r....@gmail.com> on 2013/05/21 16:36:52 UTC
CXF issue with all CAPS fields (follow up and resolution)
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
Re: CXF issue with all CAPS fields (follow up and resolution)
Posted by rouble <r....@gmail.com>.
Dan,
I agree that there is nothing more for the CXF team to do now.
However, we do need a test case to avoid releasing CXF releases that
completely break existing deployments with no workarounds (especially
for something as innocuous as choice of case of member variables).
With a unit test case in place, this issue can simply be avoided by
skipping the offending version of JAXB.
Inline.
> This is honestly not something I'm planning on spending much more time on as, IMO, it's not a bug in CXF or, even if it is, would require some support for Oracle. If it's an interaction problem between CXF and JAXB, then Oracle has the same problem with their JAX-WS tools and the root of the problem needs to be fixed on their side first.
>
> It's very simple, take your test case and run:
>
> wsgen -cp . -wsdl com.example.FooWebServiceImpl
>
> with both the latest Java6 (jaxb 2.1 based) and the latest Java7. With Java6, you get:
>
> <xs:element name="FOO" type="tns:FOO" minOccurs="0"/>
>
> and with Java7:
>
> <xs:element ref="tns:FOO" minOccurs="0"/>
>
> No CXF involved at all.
Actually, one point I was trying to make is that it is *not* the WSDL
generation that is the issue. Using JAXB 2.2.6 the same element
reference is created in the WSDL - but the client side *is* able to
unmarshall FOO correctly, and JAXB 2.2.4 client is unable to
unmarshall FOO correctly. You can try my testcase with CXF 2.6.0 to
verify. So, it is a client side unmarshalling issue.
I do not think this issue exists with Java7 since they use JAXB 2.2.6
- though I have not tried an end to end test.
I will work to add a CXF unit testcase.
Cheers
Rouble
>
>
> > 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.
>
>
> > 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....@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
>
Re: CXF issue with all CAPS fields (follow up and resolution)
Posted by Freeman Fang <fr...@gmail.com>.
－－－－－－－－－－－－－
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....@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
>
Re: CXF issue with all CAPS fields (follow up and resolution)
Posted by Daniel Kulp <dk...@apache.org>.
This is honestly not something I'm planning on spending much more time on as, IMO, it's not a bug in CXF or, even if it is, would require some support for Oracle. If it's an interaction problem between CXF and JAXB, then Oracle has the same problem with their JAX-WS tools and the root of the problem needs to be fixed on their side first.
It's very simple, take your test case and run:
wsgen -cp . -wsdl com.example.FooWebServiceImpl
with both the latest Java6 (jaxb 2.1 based) and the latest Java7. With Java6, you get:
<xs:element name="FOO" type="tns:FOO" minOccurs="0"/>
and with Java7:
<xs:element ref="tns:FOO" minOccurs="0"/>
No CXF involved at all.
> 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.
> 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....@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