POX literal fault is not detected by client
--------------------------------------------
Key: AXIS2-3771
URL: https://issues.apache.org/jira/browse/AXIS2-3771
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: transports
Affects Versions: 1.3
Environment: Debian etch. JVM 1.4 from blackdown (64 bits)
Reporter: Xavi Drudis Ferran
Priority: Minor
Sorry if this is not a bug, I may well have misunderstood something. I tend to
think it's a bug because an exception
in the server does not reach the client when both use code generated by
WSDL2Java, but maybe what I'm trying can't be done.
I have to code a client for a webservice that answers with a xml response when
accessed through a GET with parameters.
The returned xml has a certain root element when things work and otherwise the
root element is <error description="..."/>
So I defined a wsdl for the web service with literal response and a literal
fault that describe the xml issued on
success and error respectively.
I generated a client and a server for tests (the real server is going to
be by a third partly, so I have to make my test server behave as close as
the specification of the third party server as I can). The server seems to work
as specified (after some configuration tweaking for REST and
namespacelessness).
The client works in case of success, but when the server skeleton throws the
ERRORMessage exception (generated by WSDL2Java)
an <error description="..."/> response gets to the client, and then the client
throws an exception like this:
java.lang.IllegalArgumentException: The MessageContext does not have an
associated SOAPFault.
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:478)
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
...
By a quick look at the code it would seem that because it's a REST client (POX,
actually, I think), the OutInAxisOperationClient.handleResponse method has to
make up an envelope it didn't get, and calls
TransportUtils.createSOAPMessage(responseMessageContext);
and with the generated envelope it somehow detects there's a fault and calls
Utils.getInboundFaultFromMessageContext(responseMessageContext);
to throw the corresponding exception (which should be the ERRORMessage
generated by WSDL2Java).
But it seems to be unable to see it's an ERRORMessage the exception it should
create and throw.
Might it be because TransportUtils.createSOAPMessage(responseMessageContext)
calls (indirectly) createSOAPEnvelope with a document created from
the <error description="..."/> response, and so it treats the fault as the
document, and later the getInboundFaultFromMessageContext cannot find
the fault because it has been mistakenly taken for the body ?
In other words, the code that parses a REST response in the client
does not seem (at first glance) to expect a literal fault as declared in
the wsdl when generating a fake envelope for the rest of axis2 to
treat as if it where a SOAP response. Should this be changed or
it's not a covered use case and so it should remain as is?.
Sorry if I don't give enough detail, I thought of sending code, but
maybe it'd be best to build a simpler example than what I have (modifying
the getVersion sample, or whatever), also helping to isolate the issue.
I may do it later this week if you think it's worthwhile.
I'm just sending this in order to know whether what I try to do
makes sense and should be further investigated or is just nonsense
and I should learn how to use Axis2 better. Wasn't sure whether I
should use JIRA or a mailing list, but thought we can close the bug if
it's not one.
--
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]
