[ 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

Reply via email to