ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Deployment issue in WAS 7 server (Web Sphere Application Server) #### CXF 2.7 + Neethi 3.0.2
Date Mon, 19 Nov 2012 17:44:24 GMT

On Nov 18, 2012, at 3:04 PM, Martin Gainty <mgainty@hotmail.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message