On Nov 18, 2012, at 3:04 PM, Martin Gainty <[email protected]> wrote:
> Hi Benson > anyone desiring to introduce camel case complex-elements from any approved > XSD will > 1)always succeed generating the resulting Java ComplexElement classes with > Axis > 2)will always fail generating Java ComplexElement classes with Apache-CXF.. There are two kinds of failures for this scenario: 1) unexpected failures such as NPE's or other crashes. Thus are generally critical bugs that I'd certainly like to know about to make sure they are fixed. 2) "expected" failures due to spec compliance - these are things like two schema types that would map to the same class name or the WSDL not being WSI-BP compliant or similar. In these cases, CXF SHOULD be providing a decent enough error or warning message about what the issue is. Your description above doesn't really provide enough context about which type of failure you are encountering. If it's the first, that's a major issue that needs to be fixed. If it's the latter, it would depend on the warning/error. CXF does provide some leeway and options to work around some types of issues either through things like jaxb/jaxws binding files or wsdl2java flags (example: -autoNameResolution to work around some of the classname conflicts, -validate=none for various invalid wsdl constructs, etc...). However, if the wsdl is completely against normal specifications, it may be difficult. If the issue is in the schema mapping, another option is to flip from JAXB to one of the other data bindings. JAXB certainly does have a few restrictions that are difficult to work around. CXF supports both XmlSchema and JBIX as alternatives. > to be fair the contingency of handling camelcase complex-elements was never > considered in the original JAX-WS spec but > the guy with the red tie (the same guy with the big checkbook) wants a demo > in 5 min then I'll opt for Axis > > <2Cents> > it was a horrible shame to toss the CXF code *that we had invested .5 man > year into* based on the failed camelcase testcases.. > My genuine desire was and is to get ESB and CXF Wsdl2Java working as No other > product comes close to the functionality we enjoyed with a working ESB > I researched alternatives to ESB (and NMR backbone) and did'nt find any.. > we *sort of* accomplished the same objective as ESB with Axis thru our > quickly crafted Aggregator UberService (replacement for Camel) > that would handle response with XSLT transformed HTML (replacement for Camel) > </2Cents> > > in any case this looks like a low workload week so please let me know what i > can do to help to get this issue identified (and fixed) Well, the answer is the same for any issue (and pretty much any project): 1) File a JIRA - from what I can tell, all the JIRA's related to this issue have been marked fixed. Thus, if there is still an issue, get an issue filed with as complete a description as possible. 2) Add a test case to the JIRA - this is the #1 thing that a user can do to help the developers diagnose and fix a bug. If there is a test case provided, it SIGNIFICANTLY reduces the amount of time a developer needs to spend to figure out what is going on. In general, I'm way way more likely to have the time to look at a bug if there is a test case there. Bonus points if the test case uses Maven. :-) 3) Attach a patch - CXF *IS* open source, patches are always welcome. :-) -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
