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 <[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 >
