Bad namespaces in serialized beans in doc/literal

• Key: AXIS-1529
• Type: Bug
• Status: Open
• Priority: Major
• Assignee: Unassigned
• Reporter: Tudor Teusan
• Component/s: Serialization/Deserialization
• Affects Version/s: current (nightly)

Description

It seems that AXIS (latest CVS) doesn't serialize properly complex
objects (beans) when in doc/literal.

More precisely it doesn't handle as it should a SOAP body with multiple namespaces, as shown in the following exemple :
(I've come upon this problem trying to return a tree structure from a
web service)

The service is a TreeProvider defined as

---
class TreeProvider {
   private Node root;
   ...
   public Node getTree(){ return root; }
   ...
}
---

Node being a very simple bean with two attributes : id and name.

---
class Node {
   private String id, name;
   public string getName(){ return name; }
   ...
}
---

Node and TreeProvider are in 2 different packages
"com.knowesis.ws.TreeProvider" and "com.knowesis.tree.Node" ( left out for brevity).

In the constructor of TreeProvider the root node is initilized as
id="root", name="root".

The deploy.wsdd is :

---
...
<service name="TreeProvider" style="document" use="literal">
<namespace>urn:AthanorWS:ws</namespace>

 <parameter name="className" value="com.knowesis.ws.TreeProvider"/>
 <parameter name="allowedMethods" value="getTree"/>

 <beanMapping xmlns:data="urn:AthanorWS:data" qname="data:Node"
    languageSpecificType="java:com.knowesis.tree.Node"/>

</service>
...
---

the service gets deployed ok and the types section in the auto-generated wsdl looks like this :

---
...
<wsdl:types>
   <schema elementFormDefault="qualified"
        targetNamespace="urn:AthanorWS:data"
        xmlns="http://www.w3.org/2001/XMLSchema">
      
        <complexType name="Node">
           <sequence>
               <element name="id" nillable="true" type="xsd:string" />
               <element name="name" nillable="true" type="xsd:string"
/>
           </sequence>
       </complexType>
   </schema>

   <schema elementFormDefault="qualified"
        targetNamespace="urn:AthanorWS:ws"
        xmlns="http://www.w3.org/2001/XMLSchema">

       <import namespace="urn:AthanorWS:data" />
       <element name="getTreeReturn" type="tns1:Node" />
   </schema>
</wsdl:types>
...
---

notice the the two namespaces (and this is how it should be) and the
elementFormDefault="qualified" for the two schemas.
A getTree() invocation results in :

---
...
<soapenv:Body>
   <getTreeReturn xmlns="urn:AthanorWS:ws">
      <id>root</id>
      <name>root</name>
   </getTreeReturn>
</soapenv:Body>
...
---

The contents of the generated body is not valid with respect to the wsdl specified schemas.

"id" and "root" elements are in the same namespace as "getTreeReturn"
(urn:AthanorWS:ws) instead of being in their own "urn:AthanorWS:data"
namespace :

<getTreeReturn xmlns="urn:AthanorWS:ws">
   <id xmlns="urn:AthanorWS:data">root</id>
   <name xmlns="urn:AthanorWS:data">root</name>
</getTreeReturn>

As a direct consequence a generated .Net client simply refuses to
deserialize the response and always returns an empty answer.

Comments

[John Busfield]

AXIS-2473 and AXIS-2449 describe the same issue and are also unresolved.

[Per Salomonsson]

I have attached a patch (and a patched lib) compatible with 1.4.0 release/branch.
The problem we had was when using document/literal wrapped complex types were not serialized correctly (missing namespaces). I have also included a fix for using arrays. them "item" tag is now used (to match the xml schema in the WSDL file), and with the correct namespace. The array-fix is taken more or less from another bugreport that was reported here at JIRA.

Please let me know if it works for you to.
Here is how we have used it:

1. Write the java classes that should represent the web service interface - including your java beans.
2. generate deploy/undeploy wsdd's using ant task "axis-wsdl2java" (DOCUMENT/LITERAL WRAPPED)
3. startup the server and publish the services.

The patch has only been used/tested with axis on the serverside, on the client side we have used 2 other client implementations to test/verify.

[Per Salomonsson]

And the patched jar.

[Adam Crume]

I'm very grateful for the patch that was supplied! I'm not familiar enough with the Axis source code to fix the issue myself. However, the patch had a couple of issues, so I attached a patch that should be applied after the first one to fix those issues.
1. Bean property names were not always capitalized correctly. See the Javadoc for java.beans.Introspector.decapitalize(String). I modified the code to use org.apache.axis.utils.BeanUtils instead of doing it manually.
2. There was a line in org.apache.axis.encoding.SerializationContext.serializeActual that was using == to compare strings. I changed it to "".equals(blah). I didn't see a bug caused by this, but I wanted to be proactive.

[Adam Crume]

We ran into an issue with the patch breaking deserialization of beans with properties that are arrays of beans in doc/lit. This new patch (axis-patch3.txt) appears to fix the issue, but I don't really understand all of the mechanics behind Axis. I commented out a section of code that may be necessary in some situations (maybe the difference is wrapped vs. unwrapped documents?).