You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Bobby Lawrence (JIRA)" <ax...@ws.apache.org> on 2005/04/04 20:23:20 UTC
[jira] Created: (AXIS-1909) Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
--------------------------------------------------------------------------------------
Key: AXIS-1909
URL: http://issues.apache.org/jira/browse/AXIS-1909
Project: Axis
Type: Bug
Components: Basic Architecture
Environment: Windows XP Pro, Java 1.4.2, Axis 1.2 RC3
Reporter: Bobby Lawrence
I have a client that uploads data to the service.
I wanted the ability to upload a single XML Document, so I wrote a method to do so using the SAAJ API.
With the SAAJ API, you have to create a SOAPConnection and call its 'call' method.
In the Axis implementation of this, it creates a Call object and invokes.
The Call object internally calls the 'invokeEngine' method.
Inside this method, there is a piece of code that checks to see if the returned object is a SOAPFault (below).
If we have a fault, the method throws an AxisFault if there are some things about the OperationDesc that it knows.
I think that this OperationDesc checking needs to be removed and ALL faults should be thrown back up the exception chain.
I had my client uploading a dateTime type with 'asgasdg' as the value of the element. The server side deserialization threw a fault (java.lang.NumberFormatException: Invalid date/time), but the client just did nothing. It looked to be that the client had completed its data upload processing and everything worked fine when in fact, it didn't upload anything and there was an error!
if(operation == null ||
operation.getReturnClass() == null ||
operation.getReturnClass() != javax.xml.soap.SOAPMessage.class
) {
//unless we don't care about the return value or we want
//a raw message back
//get the fault from the body and throw it
throw ((SOAPFault)respBody).getFault();
}
--
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
[jira] Updated: (AXIS-1909) Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
Posted by "Bobby Lawrence (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1909?page=all ]
Bobby Lawrence updated AXIS-1909:
---------------------------------
Attachment: TestCase.jar
Don't know why I need to upload a test case, I thought the problem was pretty clear...
The problem is that RemoteException (AxisFault) is only thrown in certain cases in the "invokeOneWay" method of the Call object.
Maybe that was intentional, but in the current implementation of the SAAJ API, I have to get the response and parse it fully to determine if we have gotten a fault returned from the service. This is completely different from the JAX-RPC API where any fault is thrown in the form of a RemoteException.
I think that if the client Call object gets a fault returned, it should throw an Exception.
Maybe I shouldn't have classified it this issue as a bug, but it sure looked like one when I found the problem...my original webservice didn't really return anything.
> Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
> --------------------------------------------------------------------------------------
>
> Key: AXIS-1909
> URL: http://issues.apache.org/jira/browse/AXIS-1909
> Project: Axis
> Type: Bug
> Components: Basic Architecture
> Environment: Windows XP Pro, Java 1.4.2, Axis 1.2 RC3
> Reporter: Bobby Lawrence
> Attachments: TestCase.jar
>
> I have a client that uploads data to the service.
> I wanted the ability to upload a single XML Document, so I wrote a method to do so using the SAAJ API.
> With the SAAJ API, you have to create a SOAPConnection and call its 'call' method.
> In the Axis implementation of this, it creates a Call object and invokes.
> The Call object internally calls the 'invokeEngine' method.
> Inside this method, there is a piece of code that checks to see if the returned object is a SOAPFault (below).
> If we have a fault, the method throws an AxisFault if there are some things about the OperationDesc that it knows.
> I think that this OperationDesc checking needs to be removed and ALL faults should be thrown back up the exception chain.
> I had my client uploading a dateTime type with 'asgasdg' as the value of the element. The server side deserialization threw a fault (java.lang.NumberFormatException: Invalid date/time), but the client just did nothing. It looked to be that the client had completed its data upload processing and everything worked fine when in fact, it didn't upload anything and there was an error!
> if(operation == null ||
> operation.getReturnClass() == null ||
> operation.getReturnClass() != javax.xml.soap.SOAPMessage.class
> ) {
> //unless we don't care about the return value or we want
> //a raw message back
> //get the fault from the body and throw it
> throw ((SOAPFault)respBody).getFault();
> }
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1909) Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
Posted by "Bobby Lawrence (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1909?page=comments#action_62129 ]
Bobby Lawrence commented on AXIS-1909:
--------------------------------------
The only workaround I have found for this (besides creating my own call object and removing the OperationDec checking) is to create my own SOAPConnection object and explicitly set the return type of the call to something other than javax.xml.soap.SOAPMessage.class
For my purposes, I use a boolean return type so I call.setReturnType(boolean.class)
> Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
> --------------------------------------------------------------------------------------
>
> Key: AXIS-1909
> URL: http://issues.apache.org/jira/browse/AXIS-1909
> Project: Axis
> Type: Bug
> Components: Basic Architecture
> Environment: Windows XP Pro, Java 1.4.2, Axis 1.2 RC3
> Reporter: Bobby Lawrence
>
> I have a client that uploads data to the service.
> I wanted the ability to upload a single XML Document, so I wrote a method to do so using the SAAJ API.
> With the SAAJ API, you have to create a SOAPConnection and call its 'call' method.
> In the Axis implementation of this, it creates a Call object and invokes.
> The Call object internally calls the 'invokeEngine' method.
> Inside this method, there is a piece of code that checks to see if the returned object is a SOAPFault (below).
> If we have a fault, the method throws an AxisFault if there are some things about the OperationDesc that it knows.
> I think that this OperationDesc checking needs to be removed and ALL faults should be thrown back up the exception chain.
> I had my client uploading a dateTime type with 'asgasdg' as the value of the element. The server side deserialization threw a fault (java.lang.NumberFormatException: Invalid date/time), but the client just did nothing. It looked to be that the client had completed its data upload processing and everything worked fine when in fact, it didn't upload anything and there was an error!
> if(operation == null ||
> operation.getReturnClass() == null ||
> operation.getReturnClass() != javax.xml.soap.SOAPMessage.class
> ) {
> //unless we don't care about the return value or we want
> //a raw message back
> //get the fault from the body and throw it
> throw ((SOAPFault)respBody).getFault();
> }
--
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
[jira] Commented: (AXIS-1909) Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1909?page=comments#action_63559 ]
Davanum Srinivas commented on AXIS-1909:
----------------------------------------
can you please upload a test case i can use to recreate the problem.
thanks,
dims
> Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
> --------------------------------------------------------------------------------------
>
> Key: AXIS-1909
> URL: http://issues.apache.org/jira/browse/AXIS-1909
> Project: Axis
> Type: Bug
> Components: Basic Architecture
> Environment: Windows XP Pro, Java 1.4.2, Axis 1.2 RC3
> Reporter: Bobby Lawrence
>
> I have a client that uploads data to the service.
> I wanted the ability to upload a single XML Document, so I wrote a method to do so using the SAAJ API.
> With the SAAJ API, you have to create a SOAPConnection and call its 'call' method.
> In the Axis implementation of this, it creates a Call object and invokes.
> The Call object internally calls the 'invokeEngine' method.
> Inside this method, there is a piece of code that checks to see if the returned object is a SOAPFault (below).
> If we have a fault, the method throws an AxisFault if there are some things about the OperationDesc that it knows.
> I think that this OperationDesc checking needs to be removed and ALL faults should be thrown back up the exception chain.
> I had my client uploading a dateTime type with 'asgasdg' as the value of the element. The server side deserialization threw a fault (java.lang.NumberFormatException: Invalid date/time), but the client just did nothing. It looked to be that the client had completed its data upload processing and everything worked fine when in fact, it didn't upload anything and there was an error!
> if(operation == null ||
> operation.getReturnClass() == null ||
> operation.getReturnClass() != javax.xml.soap.SOAPMessage.class
> ) {
> //unless we don't care about the return value or we want
> //a raw message back
> //get the fault from the body and throw it
> throw ((SOAPFault)respBody).getFault();
> }
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1909) Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
Posted by "Bobby Lawrence (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1909?page=comments#action_62275 ]
Bobby Lawrence commented on AXIS-1909:
--------------------------------------
Just to state -
The Axis implementation of the SOAPConnection (SOAPConnectionImpl) explicitly sets the return type of the Call object to 'java.xml.soap.SOAPMessage.class'. This is because it doesn't know the return type of the service.
Since this is the case, if using SAAJ to communicate w/ the webservice, a client-side fault will never be thrown and the client will never know an error occurred.
> Fault returned from server, but not thrown by org.apache.axis.client.Call.invokeEngine
> --------------------------------------------------------------------------------------
>
> Key: AXIS-1909
> URL: http://issues.apache.org/jira/browse/AXIS-1909
> Project: Axis
> Type: Bug
> Components: Basic Architecture
> Environment: Windows XP Pro, Java 1.4.2, Axis 1.2 RC3
> Reporter: Bobby Lawrence
>
> I have a client that uploads data to the service.
> I wanted the ability to upload a single XML Document, so I wrote a method to do so using the SAAJ API.
> With the SAAJ API, you have to create a SOAPConnection and call its 'call' method.
> In the Axis implementation of this, it creates a Call object and invokes.
> The Call object internally calls the 'invokeEngine' method.
> Inside this method, there is a piece of code that checks to see if the returned object is a SOAPFault (below).
> If we have a fault, the method throws an AxisFault if there are some things about the OperationDesc that it knows.
> I think that this OperationDesc checking needs to be removed and ALL faults should be thrown back up the exception chain.
> I had my client uploading a dateTime type with 'asgasdg' as the value of the element. The server side deserialization threw a fault (java.lang.NumberFormatException: Invalid date/time), but the client just did nothing. It looked to be that the client had completed its data upload processing and everything worked fine when in fact, it didn't upload anything and there was an error!
> if(operation == null ||
> operation.getReturnClass() == null ||
> operation.getReturnClass() != javax.xml.soap.SOAPMessage.class
> ) {
> //unless we don't care about the return value or we want
> //a raw message back
> //get the fault from the body and throw it
> throw ((SOAPFault)respBody).getFault();
> }
--
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