[
https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Buss reopened AXIS2-2246:
-----------------------------
We have been testing with the March16, 2007 SNAPSHOT build and I have confirmd
that an adb client generated from that build using the wsdl3java command line
tool sends the rpc-lit message correctly at least for the example I originally
attached to this bug. so siome part of this bug is fixed
However the generated server does not accept this message and instead returns
an empty fault like this
<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope xmlns:wsa="http://www.w3.org/2005/08/addressing";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Header>
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:Action>http://www.w3.org/2005/08/addressing/soap/fault</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<faultcode></faultcode>
<faultstring></faultstring>
<detail />
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
and the following error is reported:
SEVERE: java.lang.NoSuchMethodError: org.apache.axiom.soap.impl.builder.StAXSOAP
ModelBuilder: method <init>(Ljavax/xml/stream/XMLStreamReader;)V not found
I tried to debug this but unfrotunately I could not get beyond the line
StAXBuilder builder = new StAXSOAPModelBuilder(streamReader);
in SOAPBuilder.processDocument. on the server I was unable to step in and an
error is thrown. For some reason I was unable to get the log4J to dispaly
DEBUG logs either.
Further we believe that the current fix does not work on more complex schema.
It seems that under some circumstance the resulting generated client will send
document literal style messages and in that case a working server is created
although obviously neither function as intended. I noted this problem with the
original bug and I believe we are still seeing it. We have yet to characterize
it with a test case.
> Rpc-Literal Client and Server adb codegen create messages that are non WS-I
> complient
> --------------------------------------------------------------------------------------
>
> Key: AXIS2-2246
> URL: https://issues.apache.org/jira/browse/AXIS2-2246
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb
> Affects Versions: 1.1.1
> Environment: Axis 1.5, Tomcat 5.5, Axis2 1.1.1, Axis2 Eclipse codegen
> plugin 1.1.1, Eclipse 3.2, WTP 1.5.1, Windows 2003 server
> Reporter: Tim Buss
> Priority: Critical
> Attachments: Axis2RPCLiteralTest.wsdl
>
>
> There appears to be two problems. The most obvious is that the RPC-literal
> message sent by the generated client and accepted by the generated service is
> incorrect . The following message body is sent for the various test cases I
> have tried - string, complex type, nested complex type.
> <soapenv:Body>
> <ns:OperationName>
> <ns:PartName>
> .............content.....
> </ns:PartName>
> </ns:OperationName>
> </soapenv:Body>
> but it should be:
> <soapenv:Body>
> <ns:OperationName>
> <PartName>
> .............content.....
> </PartName>
> </ns:OperationName>
> </soapenv:Body>
> PartName should be a non qualified name. Axis 1.3 did it this way, and other
> sources support this as being the correct form for rpc-literal. In
> particualr WS-I Basic 1.0 states:
> "4.7.20 Part Accessors
> For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any, the
> accessor elements for parameters and return value are a part of. Different
> implementations make different choices, leading to interoperability problems.
> R2735 An ENVELOPE described with an rpc-literal binding MUST place the part
> accessor elements for parameters and return value in no namespace.
> R2755 The part accessor elements in a MESSAGE described with an rpc-literal
> binding MUST have a local name of the same value as the name attribute of the
> corresponding wsdl:part element.
> Settling on one alternative is crucial to achieving interoperability. The
> Profile places the part accessor elements in no namespace as doing so is
> simple, covers all cases, and does not lead to logical inconsistency. "
> http://www.ws-i.org/Profiles/BasicProfile-1.2.html
> The second problem that I have yet to narrow down is that with a much more
> complex type, the generated client sends a message with a body like this
> where the "part" element is not present:
> <soapenv:Body>
> <ns:OperationName>
> .............content.....
> </ns:OperationName>
> </soapenv:Body>
> One other difference that may be a factor in this case is that my complex
> service is one way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
