
|
If you were logged in you would be able to see more operations.
|
|
|
XFire
Created: 13/Nov/06 06:04 PM
Updated: 06/Jan/07 08:38 AM
|
|
| Component/s: |
Aegis Module
|
| Affects Version/s: |
1.2.2
|
| Fix Version/s: |
1.2.4
|
|
|
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 » |
|