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 "Peter Canning (JIRA)" <ax...@ws.apache.org> on 2004/11/11 21:30:23 UTC

[jira] Created: (AXIS-1662) Missing xsi:type when a web service throws a fault that is an extension of the declared fault

Missing xsi:type when a web service  throws a fault that is an extension of the declared fault
----------------------------------------------------------------------------------------------

         Key: AXIS-1662
         URL: http://nagoya.apache.org/jira/browse/AXIS-1662
     Project: Axis
        Type: Bug
  Components: Serialization/Deserialization  
    Versions: 1.2RC1    
 Environment: Linux (debian testing distribution)
JDK 1.4.2 (blackdown 1.4.2-rc1)
Axis 1.2RC1
    Reporter: Peter Canning


I started from a WSDL specification that defines a complexType BaseException which is used as the type of an element used in a message that us used for the fault of an operation.  It also defines a complex type DerivedException that is an extension of BaseException.  I generate both server and client stubs using WSDLToJava, and fill in the bodies of the methods in the ...Impl class in the server stubs.  I then write a client using client stubs to exercise the web service.

Using SimpleAxisServer to run the web service, when the ...Impl method (which is declared to throw a BaseException) throws a DerivedException, the web service correctly serializes the additional elements in the DerivedException, but it does not serialize an xsi:type to specify that the element has type DerivedException rather than BaseException.  As a result, the Axis client fails, reporting the error:

Exception in thread "main" AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: org.xml.sax.SAXException: Invalid element in exceptionTest.client.BaseException - size


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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-1662) Missing xsi:type when a web service throws a fault that is an extension of the declared fault

Posted by "Peter Canning (JIRA)" <ax...@ws.apache.org>.
     [ http://nagoya.apache.org/jira/browse/AXIS-1662?page=comments#action_55639 ]
     
Peter Canning commented on AXIS-1662:
-------------------------------------

I forgot to mention that it appears at least one other person has encountered this problem.  There is a message on the axis-user mailing list describing the problem.  There are currently no responses to the message.  You can follow this link:
http://marc.theaimsgroup.com/?l=axis-user&m=108732974329658&w=2
to see the message.

> Missing xsi:type when a web service  throws a fault that is an extension of the declared fault
> ----------------------------------------------------------------------------------------------
>
>          Key: AXIS-1662
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1662
>      Project: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2RC1
>  Environment: Linux (debian testing distribution)
> JDK 1.4.2 (blackdown 1.4.2-rc1)
> Axis 1.2RC1
>     Reporter: Peter Canning
>  Attachments: ExceptionTestBindingImpl.java, exceptionTest.wsdl, exceptionTestClient.java
>
> I started from a WSDL specification that defines a complexType BaseException which is used as the type of an element used in a message that us used for the fault of an operation.  It also defines a complex type DerivedException that is an extension of BaseException.  I generate both server and client stubs using WSDLToJava, and fill in the bodies of the methods in the ...Impl class in the server stubs.  I then write a client using client stubs to exercise the web service.
> Using SimpleAxisServer to run the web service, when the ...Impl method (which is declared to throw a BaseException) throws a DerivedException, the web service correctly serializes the additional elements in the DerivedException, but it does not serialize an xsi:type to specify that the element has type DerivedException rather than BaseException.  As a result, the Axis client fails, reporting the error:
> Exception in thread "main" AxisFault
>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
>  faultSubcode: 
>  faultString: org.xml.sax.SAXException: Invalid element in exceptionTest.client.BaseException - size

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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-1662) Missing xsi:type when a web service throws a fault that is an extension of the declared fault

Posted by "Peter Canning (JIRA)" <ax...@ws.apache.org>.
     [ http://nagoya.apache.org/jira/browse/AXIS-1662?page=history ]

Peter Canning updated AXIS-1662:
--------------------------------

    Attachment: exceptionTest.wsdl
                exceptionTestClient.java
                ExceptionTestBindingImpl.java

I've attached the WSDL file, the test client exceptionTestClient.java, and the ExceptionTestBindingImpl.java containing the implementation of the web service operations.
I generate the client and server stubs using the following commands:
WSDL2Java -v -p exceptionTest.client -o stubs exceptionTest.wsdl
WSDL2Java -v -p exceptionTest.server -o stubs --server-side --skeletonDeploy true exceptionTest.wsdl

The erroneous behavior occurs after line 43 of ExceptionTestBindingImpl.java, where the method throwException() throws derivedException.
The erroneous behavior occurs when serializing the fault in response to the method throwException() throwing derivedException at line 43 of ExceptionTestBindingImpl.java.

> Missing xsi:type when a web service  throws a fault that is an extension of the declared fault
> ----------------------------------------------------------------------------------------------
>
>          Key: AXIS-1662
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1662
>      Project: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2RC1
>  Environment: Linux (debian testing distribution)
> JDK 1.4.2 (blackdown 1.4.2-rc1)
> Axis 1.2RC1
>     Reporter: Peter Canning
>  Attachments: ExceptionTestBindingImpl.java, exceptionTest.wsdl, exceptionTestClient.java
>
> I started from a WSDL specification that defines a complexType BaseException which is used as the type of an element used in a message that us used for the fault of an operation.  It also defines a complex type DerivedException that is an extension of BaseException.  I generate both server and client stubs using WSDLToJava, and fill in the bodies of the methods in the ...Impl class in the server stubs.  I then write a client using client stubs to exercise the web service.
> Using SimpleAxisServer to run the web service, when the ...Impl method (which is declared to throw a BaseException) throws a DerivedException, the web service correctly serializes the additional elements in the DerivedException, but it does not serialize an xsi:type to specify that the element has type DerivedException rather than BaseException.  As a result, the Axis client fails, reporting the error:
> Exception in thread "main" AxisFault
>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
>  faultSubcode: 
>  faultString: org.xml.sax.SAXException: Invalid element in exceptionTest.client.BaseException - size

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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-1662) Missing xsi:type when a web service throws a fault that is an extension of the declared fault

Posted by "Jayachandra Sekhara Rao Sunkara (JIRA)" <ax...@ws.apache.org>.
     [ http://nagoya.apache.org/jira/browse/AXIS-1662?page=comments#action_55528 ]
     
Jayachandra Sekhara Rao Sunkara commented on AXIS-1662:
-------------------------------------------------------

Hi Peter!
Without the filling code of the ..BindingImpl file, I'm afraid replicating the problem would be tough? Try to post the filling code also

Thank you,
Jayachandra

> Missing xsi:type when a web service  throws a fault that is an extension of the declared fault
> ----------------------------------------------------------------------------------------------
>
>          Key: AXIS-1662
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1662
>      Project: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2RC1
>  Environment: Linux (debian testing distribution)
> JDK 1.4.2 (blackdown 1.4.2-rc1)
> Axis 1.2RC1
>     Reporter: Peter Canning
>  Attachments: ExceptionTestBindingImpl.java, exceptionTest.wsdl, exceptionTestClient.java
>
> I started from a WSDL specification that defines a complexType BaseException which is used as the type of an element used in a message that us used for the fault of an operation.  It also defines a complex type DerivedException that is an extension of BaseException.  I generate both server and client stubs using WSDLToJava, and fill in the bodies of the methods in the ...Impl class in the server stubs.  I then write a client using client stubs to exercise the web service.
> Using SimpleAxisServer to run the web service, when the ...Impl method (which is declared to throw a BaseException) throws a DerivedException, the web service correctly serializes the additional elements in the DerivedException, but it does not serialize an xsi:type to specify that the element has type DerivedException rather than BaseException.  As a result, the Axis client fails, reporting the error:
> Exception in thread "main" AxisFault
>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
>  faultSubcode: 
>  faultString: org.xml.sax.SAXException: Invalid element in exceptionTest.client.BaseException - size

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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-1662) Missing xsi:type when a web service throws a fault that is an extension of the declared fault

Posted by "Jayachandra Sekhara Rao Sunkara (JIRA)" <ax...@ws.apache.org>.
     [ http://nagoya.apache.org/jira/browse/AXIS-1662?page=comments#action_55529 ]
     
Jayachandra Sekhara Rao Sunkara commented on AXIS-1662:
-------------------------------------------------------

Oops! sorry for that. I've copied the Impl file now.

> Missing xsi:type when a web service  throws a fault that is an extension of the declared fault
> ----------------------------------------------------------------------------------------------
>
>          Key: AXIS-1662
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1662
>      Project: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2RC1
>  Environment: Linux (debian testing distribution)
> JDK 1.4.2 (blackdown 1.4.2-rc1)
> Axis 1.2RC1
>     Reporter: Peter Canning
>  Attachments: ExceptionTestBindingImpl.java, exceptionTest.wsdl, exceptionTestClient.java
>
> I started from a WSDL specification that defines a complexType BaseException which is used as the type of an element used in a message that us used for the fault of an operation.  It also defines a complex type DerivedException that is an extension of BaseException.  I generate both server and client stubs using WSDLToJava, and fill in the bodies of the methods in the ...Impl class in the server stubs.  I then write a client using client stubs to exercise the web service.
> Using SimpleAxisServer to run the web service, when the ...Impl method (which is declared to throw a BaseException) throws a DerivedException, the web service correctly serializes the additional elements in the DerivedException, but it does not serialize an xsi:type to specify that the element has type DerivedException rather than BaseException.  As a result, the Axis client fails, reporting the error:
> Exception in thread "main" AxisFault
>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
>  faultSubcode: 
>  faultString: org.xml.sax.SAXException: Invalid element in exceptionTest.client.BaseException - size

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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-1662) Missing xsi:type when a web service throws a fault that is an extension of the declared fault

Posted by "Jayachandra Sekhara Rao Sunkara (JIRA)" <ax...@ws.apache.org>.
     [ http://nagoya.apache.org/jira/browse/AXIS-1662?page=comments#action_55826 ]
     
Jayachandra Sekhara Rao Sunkara commented on AXIS-1662:
-------------------------------------------------------

Here are my observations on the issue. The error is definitely cropping becuase of xsi:type="DerivedException" not getting serialized in the server side response. This is happening because in the serializationContext 'sendXSIType' value is being set to the value of HashTable entry for sendXsiType. Though in the global configuration of the server-config.wsdd sendXsiType is set to true, it's being overridden to false at runtime when a singletonInstance SOAPService is being returned as the service specific handler. This analysis brings me to rephrase the problem, as I perceive, to be that some properties (eg. sendXsiTypes, sendMultiRefs) values are being registered differently in the 'options' LockableHashtable of axisServer and in the individual services singletonInstance objects options hashtable. In the first they both have boolean value true where as in the later case they both have boolean value false. How come!?!

Thanks,
Jayachandra

> Missing xsi:type when a web service  throws a fault that is an extension of the declared fault
> ----------------------------------------------------------------------------------------------
>
>          Key: AXIS-1662
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1662
>      Project: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2RC1
>  Environment: Linux (debian testing distribution)
> JDK 1.4.2 (blackdown 1.4.2-rc1)
> Axis 1.2RC1
>     Reporter: Peter Canning
>  Attachments: ExceptionTestBindingImpl.java, exceptionTest.wsdl, exceptionTestClient.java
>
> I started from a WSDL specification that defines a complexType BaseException which is used as the type of an element used in a message that us used for the fault of an operation.  It also defines a complex type DerivedException that is an extension of BaseException.  I generate both server and client stubs using WSDLToJava, and fill in the bodies of the methods in the ...Impl class in the server stubs.  I then write a client using client stubs to exercise the web service.
> Using SimpleAxisServer to run the web service, when the ...Impl method (which is declared to throw a BaseException) throws a DerivedException, the web service correctly serializes the additional elements in the DerivedException, but it does not serialize an xsi:type to specify that the element has type DerivedException rather than BaseException.  As a result, the Axis client fails, reporting the error:
> Exception in thread "main" AxisFault
>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
>  faultSubcode: 
>  faultString: org.xml.sax.SAXException: Invalid element in exceptionTest.client.BaseException - size

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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