You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Glen Mazza <gm...@talend.com> on 2011/02/24 16:02:24 UTC

Re: Unmarshalling exception: NaN

Best to ask on the CXF User's list, devs are on both, but many more 
people are on Users.

You can look over the wire to see what is being sent/received[1] 
differently--it could be something different, or in addition to, the NaN 
issue.  I believe we went from JAXB 2.1 to 2.2 between CXF 2.2 and 2.3, 
which could be the problem (You may be able to downgrade to JAXB 2.1 
with CXF 2.3, I'm not sure of the mechanism for that.)  JAXB 
Customizations[2] and/or Handlers/Interceptors[3] to change those NaN 
numbers are possible solutions.  Custom validators[4] might also help, 
and googling the CXF-User's list on Nabble for other ideas.

Sorry I can't be more specific for a solution, perhaps someone else can 
help.

Glen

[1] http://www.jroller.com/gmazza/entry/soap_calls_over_wireshark
[2] http://www.jroller.com/gmazza/entry/customizing_jaxb_artifacts
[3] http://www.jroller.com/gmazza/entry/blog_article_index (Topics #1 
and #2 under Assorted Topics)
[4] 
http://stackoverflow.com/questions/2195034/server-side-xml-validation-with-cxf-webservice

On 2/24/2011 9:22 AM, Aaron Ehrensberger wrote:
> Hi all,
>
> I'm hoping someone can help me out here...
>
> We recently upgraded CXF from 2.2.3 to 2.3.1.  In doing so, it would appear
> that some of our webservices have been broken in the process.
>
> Specifically, the issue we're having is that our client is passing across a
> field like<integerValue>NaN</integerValue>, which previously was being
> processed fine and we didn't have issues.  However, it would appear that
> now, we are throwing an UnmarshallingException.  Debugging through eclipse,
> we see an error like...
> DefaultValidationEventHandler: [ERROR]: Not a number: NaN
> Location: line 49  - that class comes from jaxb-api jar
>
> That said - any ideas what to look for or change?
>
> Thanks,
>
> Aaron