[
https://issues.apache.org/jira/browse/CXF-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991888#comment-12991888
]
Victor-Adrian Ichim commented on CXF-3291:
------------------------------------------
I agree with and respect the Apache CXF decision to reject that broken contract
by ignoring the xsi:nil attribute so I will close this wish as invalid.
It seems rather a JAXB limitation in the sense that it does not permit to
globally override the default nillable attribute for XmlElement. In some cases,
changing the databinding mechanism to a more flexible one like Aegis could be a
solution.
I would like to better explain the context of my "wish" because I hope this
discussion could help other developers in the same situation.
The necessity of altering the wsdl contract comes from an issue in the
java/.net interoperability.
Basically this default
{code:xml}
<xs:element minOccurs="0" name="id" type="xs:long"/>
{code:xml}
has to be changed to
{code:xml}
<xs:element name="id" nillable="true" type="xs:long"/>
{code:xml}
One reason is to reduce the complexity of .Net generated classes (see
http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/DataBinding2.html
- section Primitive and Wrappers - each wrapper class receives an addtitional
boolean property due to minOccurs="0").
The workarround above becomes invalid if you want to refactor one application
to JBoss 6.
Unfortunately I don't see simple solutions to this issue.
1. Changing the web service stack in JBoss 6 is not useful: JBossWS-Metro
support has been dropped and JBossWS-Native behavior is the same as Apache CXF
(for our nillable case).
2. Annotating all the fields with XmlElement(nillable=true) is the most correct
solution but too dirty to be acceptable for a huge number of classes involved.
3. Replacing JAXB with Aegis seems interesting but could introduce additional
overhead especially in an application which needs the wsdl2java support also.
I would appreciate any hint about another solution to this java/.Net issue.
Thank you!
> Unmarshalling null value for java.lang.Long generates an empty string
> exception
> -------------------------------------------------------------------------------
>
> Key: CXF-3291
> URL: https://issues.apache.org/jira/browse/CXF-3291
> Project: CXF
> Issue Type: Wish
> Components: JAXB Databinding
> Affects Versions: 2.3.1
> Environment: Microsoft Windows 7 Enterprise, jdk1.6.0_23, JBoss 6.0
> final which contains 2.3.1 version of CXF.
> Intel Dual Core, 3GB RAM
> Reporter: Victor-Adrian Ichim
> Fix For: Invalid
>
> Attachments: cxf3291_eclipse_projects.zip
>
>
> java.lang.Long is not unmarshalled (while primitive long works)
> Steps to reproduce:
> 1. Create a RPC-LITERAL web service on a stateless session bean with a single
> method like this:
> public ResultDTO compute(FilterDTO filter)
> FilterDTO must contain a java.lang.Long id; property.
> Annotated FilterDTO with @XmlAccessorType(XmlAccessType.FIELD)
> 2. Generate the wsdl file with org.apache.cxf.tools.java2ws.JavaToWS
> 3. Deploy the ear by including the wsdl file also (wsdlLocation is specified
> on the bean for @WebService)
> 4. Start the server and use a client to call the method. Having RPC-LITERAL
> the parameter must be not null in the request.
> So FilterDTO must be instantiated. Do not assign any value to the id field
> (let it null).
> Result:
> 16:40:36,317 INFO [STDOUT] DefaultValidationEventHandler: [ERROR]: For input
> string: ""
> 16:40:36,317 INFO [STDOUT] Location: line 1
> 16:40:36,323 WARN [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for {http://ws.ro/}ServiceFacadeService#{http://ws.ro/}compute has thrown
> exception, unwinding now: org.apache.cxf.interceptor.Fault: Unmarshalling
> Error: For input
> string: ""
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:787)
> [:2.3.1]
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:628)
> [:2.3.1]
> at
> org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:133) [:2.3.1]
> ........
> Caused by: javax.xml.bind.UnmarshalException
> - with linked exception:
> [javax.xml.bind.UnmarshalException: For input string: ""
> - with linked exception:
> [java.lang.NumberFormatException: For input string: ""]]
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425)
> [:
> 2.2]
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362)
> [:2.2]
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339)
> [:2.2]
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:764)
> [:2.3.1]
> Caused by: javax.xml.bind.UnmarshalException: For input string: ""
> - with linked exception:
> [java.lang.NumberFormatException: For input string: ""]
> ... 46 more
> Caused by: java.lang.NumberFormatException: For input string: ""
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> [:1.6.0_23]
> at java.lang.Long.parseLong(Long.java:431) [:1.6.0_23]
> at java.lang.Long.valueOf(Long.java:525) [:1.6.0_23]
> at
> com.sun.xml.bind.DatatypeConverterImpl._parseLong(DatatypeConverterImpl.java:143)
> [:2.2]
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
