WSDL2Java and literal encoding

[Thomas Sandholm <sa...@mcs.anl.gov>]

I have seen two things giving us problems with the code WSDL2Java generates 
for XML Schemas that are to be passed across the wire using literal encoding

1) The FieldName put into the TypeDescription does not match the Bean 
instance variable name, and thus the meta data is ignored.
Example:
     I want to encode my Bean instance variable name as an attribute, but 
WSDL2Java generates:
    static {
         org.apache.axis.description.FieldDesc field = new 
org.apache.axis.description.AttributeDesc();
         field.setFieldName("Name");
         field.setXmlName(new javax.xml.rpc.namespace.QName(null, "name"));
         typeDesc.addFieldDesc(field);
     };

   if I modify field.setFieldName("Name") to field.setFieldName("name") 
everything works as expected
   I guess I can't understand what the lines:

  260   String fieldName =
  261                          Utils.capitalizeFirstChar(
  262                                   Utils.xmlNameToJava(attrName));

  in org.apache.axis.wsdl.toJava.JavaComplexTypeWriter are supposed to do 
since it seems to break the meta data/instance name association.


2) The targetNamespace of the literal type is not passed across the wire. 
This makes it very hard for the server side to map the XML into the correct 
type using a TypeMappingRegistry.

I suspect 1) is a bug but 2) might be a design issue.

Maybe I should also step back and describe what we are trying to do. We 
have defined a fairly generic WSDL operation taking an xsd:anyType as input 
parameter. This parameter is defined to be passed using literal encoding 
within an rpc binding. Now we separately define arbitrary schemas 
potentially making use of attributes (i.e. not following SOAP encoding 
rules), and run these through WSDL2Java. The hope is now that we can set up 
the TypeMappings both on the server and the client side to point to the 
WSDL2Java generated stubs (Beans), so that we don't have to do any custom 
marshalling ourselves, when passing these types in the operation call.

Does this seem like a reasonable scenario?

Thanks,
     Thomas