cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <>
Subject [jira] [Resolved] (CXF-3623) WSRM AckRange's number parsing not tolerating whitespace after CXF 2.4 upgrade
Date Thu, 30 Jun 2011 09:18:28 GMT


Aki Yoshida resolved CXF-3623.

    Resolution: Fixed

> WSRM AckRange's number parsing not tolerating whitespace after CXF 2.4 upgrade
> ------------------------------------------------------------------------------
>                 Key: CXF-3623
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.4.1
>            Reporter: Aki Yoshida
>            Assignee: Aki Yoshida
>            Priority: Minor
>             Fix For: 2.4.2, 2.5
> The behavior of the number value parsing in WSRM has been changed in CXF 2.4 and this
may lead to an interoperability issue with other implementations.
> According to the whitespace handling for atomic types[1], the number types such as xs:unsignedLong
used for AcknowledgementRange's Lower/Upper values should collapse the leading and trailing
whitespace. This behavior is present in CXF 2.3.x, where type xs:unsignedLong is simply bound
to its default java type BigInteger.
> In 2.4, this type is bound to Long using the binding file. This is causing any number
value containing a leading or trailing whitespace to be not correctly read.
> I am adding the parseMethod option for the Long type in the biding file as shown below
so that the above mentioned whitespace handling is automatically provided for the Long type
by jaxb:
>                 <jaxb:javaType name="java.lang.Long"
>                     parseMethod="javax.xml.bind.DatatypeConverter.parseLong" 
>                     printMethod="javax.xml.bind.DatatypeConverter.printLong"/>
> [1], 

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message