Issue Details (XML | Word | Printable)

Key: XFIRE-753
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dan Diephouse
Reporter: Karthikeyan M.
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
XFire

"java.lang.IllegalArgumentException: argument type mismatch" when an invalid xsi:type is specified in soap request.

Created: 13/Nov/06 06:04 PM   Updated: 06/Jan/07 08:38 AM   Resolved: 06/Jan/07 08:38 AM
Return to search
Component/s: Aegis Module
Affects Version/s: 1.2.2
Fix Version/s: 1.2.4

Time Tracking:
Not Specified

Environment: Linux, XFire 1.2.2


 Description  « Hide
  • 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



Dan Diephouse added a comment - 27/Nov/06 02:18 PM

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.


Dan Diephouse made changes - 27/Nov/06 02:18 PM
Field Original Value New Value
Fix Version/s 1.2.4 [ 13035 ]
Karthikeyan M. added a comment - 21/Dec/06 03:00 PM

Yes. If we can explicitely control this behaviour it would suffice.

A better way maybe to use information already present about these services. Ex: The annotated values in case of jsr181 annotations. The service interfaces are already annotated with "@SOAPBinding(style=SOAPBinding.Style.DOCUMENT, use=SOAPBinding.Use.LITERAL, parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)".

This clearly means that the service is not using rpc encodings and hence xsi:type specified can be ignored.


Dan Diephouse added a comment - 06/Jan/07 08:38 AM

Fixed in SVN. xsi:type reading can now be disabled by setting the "readXsiType" property to "false" (or Boolean.FALSE).


Dan Diephouse made changes - 06/Jan/07 08:38 AM
Status Open [ 1 ] Closed [ 6 ]
Resolution Fixed [ 1 ]