[jira] Commented: (AXIS-1309) WSDL2Java: lost type mappings when mixing use="encoded" and use="literal"

[ji...@apache.org]

The following comment has been added to this issue:

     Author: Tom Jordahl
    Created: Wed, 14 Apr 2004 6:50 AM
       Body:
This is a "known" limitation of Axis.  We do not handle mixed operation encoding gracefully.  It would be nice to fix this, but I am afraid that the work required would be extensive.  If you would like to tackle it, that would be great.

Given the WS-I (and WSDL2.0) focus on doc/lit being the one true way, it might not be worth the effort however.

---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/AXIS-1309?page=comments#action_35019

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1309

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1309
    Summary: WSDL2Java: lost type mappings when mixing use="encoded" and use="literal"
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Axis
 Components: 
             WSDL processing
   Versions:
             1.2 Alpha
             1.1

   Assignee: 
   Reporter: Ray Plante

    Created: Tue, 13 Apr 2004 4:11 PM
    Updated: Wed, 14 Apr 2004 6:50 AM
Environment: Linux RedHat 9, kernal 2.4.21, JDK 1.4.2

Description:
I generated a client stub using WSDL2Java from a wsdl where most of the operations were bound with <wsdlsoap:body use="encoded" ...>; however, one operation had <wsdlsoap:body use="literal">.  I found that the first call to an operation worked fine; however, subsequent calls resulted in an exception complaining that it couldn't find a deserializer for ... (even though it found it fine on the first call!).

With some experimentation/debugging, I isolated the problem to the point where the type mappings are registered within the generated stub's createCall() method.  When all operations have use="encoded", createCall() contains the following bit of code:

   if (firstCall()) {
       // must set encoding style before registering serializers
       _call.setSOAPVersion(org.apache.axis.soap.SOAPConstants.SOAP11_CONSTANTS);
       _call.setEncodingStyle(org.apache.axis.Constants.URI_SOAP11_ENC);
       for (int i = 0; i < cachedSerFactories.size(); ++i) {
          ...types are registered...
       }

When all operations have use="literal", this code looks like this:

    if (firstCall()) {
       // must set encoding style before registering serializers
       _call.setEncodingStyle(null);
       for (int i = 0; i < cachedSerFactories.size(); ++i) {
          ...mappings are registered...
       }

When at least one operation is use="literal" and the remaining are use="encoded", the result is the same as if all were use="literal", as illustrated above.  

The mappings get lost because a TypeMappingRegistry segregates mappings by the encoding style.  Thus in the mixed case, the encodingStyle of the first call is set to literal (whether it is defined that way or not), and the mappings are stored assuming literal.  At deserialization time, the deserializers are found fine.  On a second call (to an "encoded" operation), the encoding style is set to encoded (the default for a new call instance).  Since no mappings were registered under this encoding style, the deserializers are not found.  

I've gotten around this easily, of course, by using literal or encoded  for all operations.  Nevertheless, I assume that since it is possible to set this on a per message basis, the above behavior is a bug.  



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira