
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
Linux, XFire 1.2.2
|
|
- This seems to be a regression in 1.2.2 compared to 1.1 - previous version of xfire I used.
- Perl clients generate xsi:type for each element even though wsdl is marked to be document, literal, wrapped style.
- Perl clients sometimes generate wrong xsi:type than the one specified in the wsdl (due to auto detection of types based on value). Ex: "1234" will have an xsi:type as xsi:int, even though it is specified as string in the wsdl.
- In the 1.2.2, xfire translates the value into java object type specified in the request element, instead of the type specified in the service interface even though the type in the request is wrong.
Ex:
wsdl snippet:
<xsd:element name="AccountID">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
request snippet:
<AccountID xsi:type="xsd:int">794683</AccountID>
- This results in:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.xfire.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:54)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler.sendMessage(ServiceInvocationHandler.java:271)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler$1.run(ServiceInvocationHandler.java:84)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler.execute(ServiceInvocationHandler.java:132)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:107)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64)
at org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38)
at org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireServletController.java:301)
at org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:130)
at org.codehaus.xfire.transport.http.XFireServlet.doPost(XFireServlet.java:116)
- Behaviour in 1.1 in the correct one, where the types specified in the request are ignored for document literal wrapped style. The correct type is the one specified in the service interface.
This issue is similar to bug http://jira.codehaus.org/browse/XFIRE-647 , which is marked to be fixed in 1.2.2
|
|
Description
|
- This seems to be a regression in 1.2.2 compared to 1.1 - previous version of xfire I used.
- Perl clients generate xsi:type for each element even though wsdl is marked to be document, literal, wrapped style.
- Perl clients sometimes generate wrong xsi:type than the one specified in the wsdl (due to auto detection of types based on value). Ex: "1234" will have an xsi:type as xsi:int, even though it is specified as string in the wsdl.
- In the 1.2.2, xfire translates the value into java object type specified in the request element, instead of the type specified in the service interface even though the type in the request is wrong.
Ex:
wsdl snippet:
<xsd:element name="AccountID">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
request snippet:
<AccountID xsi:type="xsd:int">794683</AccountID>
- This results in:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.xfire.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:54)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler.sendMessage(ServiceInvocationHandler.java:271)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler$1.run(ServiceInvocationHandler.java:84)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler.execute(ServiceInvocationHandler.java:132)
at org.codehaus.xfire.service.binding.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:107)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64)
at org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38)
at org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireServletController.java:301)
at org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:130)
at org.codehaus.xfire.transport.http.XFireServlet.doPost(XFireServlet.java:116)
- Behaviour in 1.1 in the correct one, where the types specified in the request are ignored for document literal wrapped style. The correct type is the one specified in the service interface.
This issue is similar to bug http://jira.codehaus.org/browse/XFIRE-647 , which is marked to be fixed in 1.2.2
|
Show » |
Sort Order:
Dan Diephouse made changes - 27/Nov/06 02:18 PM
| Field |
Original Value |
New Value |
|
Fix Version/s
|
|
1.2.4
[ 13035
]
|
Dan Diephouse made changes - 06/Jan/07 08:38 AM
|
Status
|
Open
[ 1
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Fixed
[ 1
]
|
|
Hmmmm... I'm not sure what the correct thing to do is here. I suppose the best thing would be to ignore the xsI:type parameter if the WRITE_XSI_TYPE flag isn't set.