cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Olivier Jacquemin (JIRA)" <>
Subject [jira] Commented: (CXF-759) Inheritance deserialization problem
Date Tue, 10 Jul 2007 14:49:05 GMT


Olivier Jacquemin commented on CXF-759:

Thank you Dan,

When trying to make the code compile after inserting your 3 lines, I noticed a very basic
fact: the CXF jar was neither on the build path nor in the classpath.  No hope of hiding any
longer that don't have much experience with Java ;-)
Note that without these 3 lines, the code compiles and runs without any reference to the CXF
jar! Is this normal? Could it be related to the jdk1.6.0 that is used? I'll install jdk1.5.0
and see if things are different.

After adding the cxf-2.0-incubator.jar to the build path, everything compiles.  I then have
to add some other jar files to the classpath for the program to run without throwing exceptions:
wsdl4j-1.6.1.jar, xml-resolver-1.2.jar, XmlSchema-1.2.jar, jaxb-impl-2.0.5.jar, geronimo-javamail_1.4_spec-1.0-M1.jar.
 cxf-2.0-incubator.jar had already been added by eclipse.

After this the client program succeeds in casting Animal to Dog, with or without the 3 lines...

However, they proved very useful on my real client program which involves
- larger data structures returned, and
- "integrated Windows authentication".
To make it work, I also had to use the local path of the WSDL file as an argument.
With the URL of the WSDL the program hangs upon web service object creation:
    new MyWebService(wsdlURL, SERVICE_NAME)
It seems to me that the WSDL file is too big and authentication fails because chunking is
not yet disabled.  What do you think? Is there a way to disable chunking before creation of
the web service?

Many thanks again,


> Inheritance deserialization problem
> -----------------------------------
>                 Key: CXF-759
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.0-RC
>         Environment: Win XP, .NET SOAP Web Service
>            Reporter: Olivier Jacquemin
>            Assignee: Dan Diephouse
>         Attachments:,,
> I am currently in the process of selecting a mechanism for building a java client for
a SOAP Web Services API developed in .NET.  This API is fairly simple, except for a point:
some data structures returned are relatively complex and involve inheritance.
> In this case, these object structures don't seem to be correctly deserialized.
> A detailed description follows: if anyone could help me either
> - improving the deserialization process in Cxf, or
> - obtaining a way to access the raw XML data (or the corresponding parsed object structure)
returned, so that the client application can complete the deserialization process itself in
an "ad hoc" way,
> I would very much appreciate it.
> Here is a very simple example after reducing the problem to its simplest form.
> /**
>  * Web service code
>  * C#
>  */
> [WebMethod]
> [XmlInclude(typeof(Dog))]
> [SoapInclude(typeof(Dog))]
> public Animal getAnimal()
> {
>     return new Dog("brown");
> }
> public class Animal // ...
> public class Dog : Animal // ...
> Here is the XML contained in the response to the invocation of getAnimal(): the xsi:type="Dog"
indicates that an instance of the daughter class is returned:
> <?xml version="1.0" encoding="utf-8"?>
> <Animal xmlns:xsi="" xmlns:xsd=""
xsi:type="Dog" xmlns="">
>   <species>Dog</species>
>   <color>brown</color>
> </Animal>
> And here is the client code, added to the auto-generated file obtained from 'wsdl2java
> /**
>  * Client code
>  * Java
>  */
> org.tempuri.Dog dog = null;
> System.out.println("Invoking getAnimal...");
> org.tempuri.Animal animal = port.getAnimal();
> try {
>     dog = (Dog)animal;
> }
> catch (java.lang.ClassCastException e1) {
>     e1.printStackTrace();
> }
> if (dog != null) {
>     System.out.println("Color of dog: " + dog.color);
> }
> The trouble is that the cast from Animal (parent class) to Dog (daughter class) fails:
a ClassCastException is thrown.
> Many thanks for any help on this issue,
>     _Olivier_

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

View raw message