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