[ http://jira.codehaus.org/browse/XFIRE-753?page=comments#action_83191 ] Karthikeyan M. commented on XFIRE-753: --------------------------------------
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. > "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
