[ http://jira.codehaus.org/browse/XFIRE-785?page=all ]
Dan Diephouse closed XFIRE-785.
-------------------------------
Resolution: Duplicate
Agreed, we should ignore the xsi:type by default. Although I'm marking this as
a duplicate of XFIRE-753 as that is basically the same problem. Watch that
issue for a resolution.
> "java.lang.IllegalArgumentException: argument type mismatch" when
> xsi:type="xsd:anyURI"
> ---------------------------------------------------------------------------------------
>
> Key: XFIRE-785
> URL: http://jira.codehaus.org/browse/XFIRE-785
> Project: XFire
> Issue Type: Bug
> Components: JAXB 2.0
> Affects Versions: 1.2.3
> Reporter: Andrew Ochsner
> Assigned To: Dan Diephouse
> Attachments: XFireAnyURIProblem.zip
>
>
> While similar to XFIRE-647 and XFIRE-753, this is slightly different and
> we're using JAXB 2.0 not Aegis.
> We have a WSDL (see attached sample project) that defines some inputs as
> xs:anyURI. We have started to see issues w/ Python clients because the
> requests they send have been a little different than Java & .NET clients.
> The request that gets sent looks like this (also included in zip):
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:test="http://test.bt.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header/>
> <soapenv:Body>
> <test:helloWorld>
> <test:inputURI xsi:type="xsd:anyURI"
> >tel:441231231231</test:inputURI>
> </test:helloWorld>
> </soapenv:Body>
> </soapenv:Envelope>
> Notice the xsi:type. xsd namespace is defined in the request as well. This
> fails w/ the IllegalArgumentException. Also included are 2 requests that
> succeed. One w/o the xsi:type (which is how .NET and Java send it) and the
> other has xsi:type="xs:anyURI" (keeping in mind that xs namespace isn't
> defined anywhere in the request...). BTW, I just used SOAPUI to send those
> requests to the service since I can't use XFire (or other Java clients) to
> recreate the issue.
> While I believe sending xsi:type in a request is bad, I can't control what my
> clients send. So, I think the correct default behavior is to just ignore any
> xsi:type hints (which is what XFIRE-753 proposes to do), which would make
> this issue moot, however, until that happens (or if it's configurable not to
> ignore it), then this issue probably needs to be solved.
--
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