cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wojtek (JIRA)" <j...@apache.org>
Subject [jira] Created: (CXF-1697) Problem with converting to Calendar
Date Thu, 10 Jul 2008 13:44:33 GMT
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
             Fix For: 2.0.4


'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.


Mime
View raw message