DO NOT REPLY [Bug 23664] New: - deserialization fails on client side for DOC/LITERAL complex types

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23664>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23664

deserialization fails on client side for DOC/LITERAL complex types

           Summary: deserialization fails on client side for DOC/LITERAL
                    complex types
           Product: Axis
           Version: current (nightly)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: steve@maring.org


I'm plugging in my own marshalling frameworks (Castor, JAXB, etc) into the (de)
serialization process for DOCUMENT/LITERAL web services.  The deserialization 
of DOCUMENT/LITERAL web services would fail only on the client side when making 
a request of an operation with no in params.

The fix for org.apache.axis.message.RPCElement follows below (diffed against a 
cvs update from last night).  It does not appear to break any of the tests in 
the buildTest.xml batchTest that do not already appear to be broken.

I can also provide my marshalling framework (de)serializers if anyone is 
interested.

diff of RPCElement.java:
223,224c223,227
<                         if ((operation.getStyle() == Style.DOCUMENT) &&
<                             operation.getNumInParams() > 0) {
---
>                         if ( ( msgContext.isClient() &&
>                               operation.getStyle() == Style.DOCUMENT ) ||
>                            ( !msgContext.isClient() &&
>                               operation.getStyle() == Style.DOCUMENT &&
>                               operation.getNumInParams() > 0 ) ) {