[ http://jira.codehaus.org/browse/XFIRE-753?page=all ]
Dan Diephouse updated XFIRE-753:
--------------------------------
Fix Version/s: 1.2.4
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.
> "java.lang.IllegalArgumentException: argument type mismatch" when an invalid
> xsi:type is specified in soap request.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: XFIRE-753
> URL: http://jira.codehaus.org/browse/XFIRE-753
> Project: XFire
> Issue Type: Bug
> Components: Aegis Module
> Affects Versions: 1.2.2
> Environment: Linux, XFire 1.2.2
> Reporter: Karthikeyan M.
> Assigned To: Dan Diephouse
> Fix For: 1.2.4
>
>
> * 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
