[jira] Resolved: (CXF-1697) Problem with converting to Calendar

["Daniel Kulp (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-1697.
------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 2.0.4)
                   2.0.8
         Assignee: Daniel Kulp

> Problem with converting to Calendar
> -----------------------------------
>
>                 Key: CXF-1697
>                 URL: https://issues.apache.org/jira/browse/CXF-1697
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.0.4
>         Environment: CXF 2.0.4
>            Reporter: Wojtek
>            Assignee: Daniel Kulp
>             Fix For: 2.0.8
>
>
> 'm receiving following error: "Unmarshalling Error: unexpected element (uri:"", local:"from"). Expected elements are (none)". It occurs when xs:dateTime is mapped to java.util.Calendar.
> Here is the part of WSDL:
>     <xs:element name="getDownloadHistory" type="getDownloadHistory"/>
>     <xs:complexType name="getDownloadHistory">
>         <xs:sequence>
>             <xs:element minOccurs="0" name="application" type="xs:string"/>
>             <xs:element minOccurs="0" name="id" type="xs:string"/>
>             <xs:element minOccurs="0" name="type" type="historyType"/>
>             <xs:element minOccurs="0" name="from" type="xs:dateTime"/>
>             <xs:element minOccurs="0" name="to" type="xs:dateTime"/>
>         </xs:sequence>
>     </xs:complexType>
>     <xs:element name="getDownloadHistoryResponse" type="getDownloadHistoryResponse"/>
>     <xs:complexType name="getDownloadHistoryResponse">
>         <xs:sequence>
>             <xs:element maxOccurs="unbounded" minOccurs="0" name="return" type="downloadRecord"/>
>         </xs:sequence>
>     </xs:complexType>
> Here is the service interface:
>     List<DownloadRecord> getDownloadHistory(
>             @WebParam(name = "application")
>             final String applicationID,
>             @WebParam(name = "id")
>             final String userID,
>             @WebParam(name = "type")
>             final HistoryType type,
>             @WebParam(name = "from")
>             final Calendar from,
>             @WebParam(name = "to")
>             final Calendar to);
> I'm using following SOAP binding:
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
>              use = SOAPBinding.Use.LITERAL,
>              parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
> Here is a SOAP request:
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:dow="http://www.volantis.com/xmlns/2008/01/mss/download-module">
>    <soapenv:Header/>
>    <soapenv:Body>
>       <dow:getDownloadHistory>
>          <!--Optional:-->
>          <application>111:222:op</application>
>          <!--Optional:-->
>          <id>666</id>
>          <!--Optional:-->
>          <type>ACTIVE</type>
>          <!--Optional:-->
>          <from>2007-02-17T14:40:32.000Z</from>
>          <to>2008-07-08T12:10:00.000Z</to>
>       </dow:getDownloadHistory>
>    </soapenv:Body>
> </soapenv:Envelope>
> And SOAP response:
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>    <soap:Body>
>       <soap:Fault>
>          <faultcode>soap:Server</faultcode>
>          <faultstring>Unmarshalling Error: unexpected element (uri:"", local:"from"). Expected elements are (none)</faultstring>
>       </soap:Fault>
>    </soap:Body>
> </soap:Envelope>
> It seems that everything is correctly configured but I still have the same error.
> I've found that in JAXBEncoderDecoder#unmarshall, in case of abstract class (like java.util.Calendar), is unmarshalled without class by JAXB what causes in result mentioned error: "Unmarshalling Error: unexpected element (uri:"", local:"from"). Expected elements are (none)".
> Here is the "if" statement checking if class is abstract.
>             if (clazz == null || (!clazz.isPrimitive() && !clazz.isArray() && !clazz.isEnum()
>                 && (Modifier.isAbstract(clazz.getModifiers())
>                 || Modifier.isInterface(clazz.getModifiers())))) {
>                 unmarshalWithClass = false;
>             }
> Is it correct "Modifier.isAbstract(clazz.getModifiers())"? Can someone confirm if it is a bug and real cause of problem? If I remove "Modifier.isAbstract(clazz.getModifiers())" everything works fine. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.