axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juergen Mayrbaeurl (JIRA)" <>
Subject [jira] Commented: (AXIS-2287) Alternative approach for stub generation
Date Wed, 08 Feb 2006 13:14:03 GMT
    [ ] 

Juergen Mayrbaeurl commented on AXIS-2287:


I've seen your sample for xbeans. But I'm still having troubles. Our webservice imports a
xml schema in the types section of the WSDL and uses complex types of the imported schema
in the message parts. The jar for the imported schema was generated with xmlbeans and namespace
mappings and excludes are correctly set up. The problem with WSDL2Java is that it will generate
type registry source code in the Stub file for every global XML element or type of the included
XML schemas and uses the names from the schemas. But XMLBeans puts the suffix "Document" to
each global XML element and type.  Therefore the type registry code will reference class names
that don't exist. Any idea? Did you have the same problem?


> Alternative approach for stub generation
> ----------------------------------------
>          Key: AXIS-2287
>          URL:
>      Project: Apache Axis
>         Type: New Feature
>     Versions: future (enh)
>     Reporter: Guy Rixon
>     Priority: Minor

> The current WSDL2Java generates Java beans for message parts and stubs that use those
beans (and, by extension, the Axis serializers/deserializers). The API into the stubs is defined
by WSDL2ava and tends to change slightly between Axis version when complex messages are used.

> Many projects like to use their own serializer/deserializer systems, typically Castor
or XMLbeans. This is possible with Axis but WSDL2Java does not support it. Many projects would
benefit from fixed stub APIs that do not change across Axis versions.
> I suggest an alternative to WSDL2Java that takes three things as input:
>   - The WSDL contract
>  - The Java interface definine the API for the stubs
>  - A list of mappings between classes and XML types.
> The latter would probably have to state both the class name and binding mechanism for
each XML type: it would have to identify the serializer and deserializer factory for the type.
Isuspect that this would be an XML document, not a simple properties file.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message