WSDL2Java problem with complex XSD file (IBM article about Axis a nd Castor together)

[Carbone Cedric <C....@NEOPOST.FR>]

Hi,

I use Axis to manage my asynchronous Document-style Web Services. I would
like to use the Castor DataBinding framework instead of the Axis one because
Axis does not  handle complex XML Schema. 
I am referring to an IBM article (Create Web services using Apache Axis and
Castor, http://www.ibm.com/developerworks/library/ws-castor/) to integrate
Axis with Castor XML.

The problem (described in this article) happens when I use the WSDL2Java
tool, with my WSDL (my WSDL import a complex XSD file (between <types>
tags)).
For each complexType, WSDL2Java generate an invalid XML by misplacing a fex
'<' and '>' in the output. For example, in the WSDD file, the qname attribut
of typeMapping tag contains 'ns:>message>request>elem'
  <typeMapping
        xmlns:ns="http://neopost.com/schema"
        qname="ns:>message>request>elem"
        type="java:com.neopost.schema._message_request_elem"
        serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
        deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
        encodingStyle=""
  />
I think the problem is that WSDL2Java replaces each underscore in the name
of data classes (this classes will be replace by Castor XML generation) with
> in WSDD file.
So the class com.neopost.schema._message_request_elem (type attribute)
becomes ns:>message>request>elem (qname attribute).

Note that this bug appears not only on a WSDD generated file. For example,
in a MessageSOAPBindingStub class, I get :
qName = new javax.xml.namespace.QName("http://neopost.com/schema",
">message>request>elem");
in the constructor.

Note that I use Axis 1.1 from CVS version (because the version 1.1 final
don't contain org.apache.axis.encoding.ser.castor.* package).

Would you have any suggestion that might help me to solve my problem ?
Do you think this could be fixed in a near future. I found the idea of
mixing Axis and Castor capabilities really appealing but I would not
recommend to use it as it is because of a obvious lack of "polish".

Regards,
___
Cedric Carbone
Neopost Industrie
cedric.carbone@brainsoft.fr