Re: WG: migrating from axis 1.1 to 1.3, .net interopability with subclasses during serialization

[Dies Koper]

Hello Thomas,

The issue you describe sounds like the one described (and fixed) in:
http://issues.apache.org/jira/browse/AXIS-2267
http://issues.apache.org/jira/browse/AXIS-2280

Please try with the nightly build.

Regards,
Dies


[EMAIL PROTECTED] wrote:

Dear Axis-users,

i'm just migrating from Axis 1.1 to Axis 1.3. I'm using axis
on both server-side and client-side (to consume various .net-
webservices) and am quite happy with its feature-richness,
performance and stability.

But some of the requests generated by Axis 1.3 as the client
implementation to consume a .net-webservice cause some problems,
which did not occur when using Axis 1.1.

Please assume the following situation:
- the .net-WSDL defines three complex types A, B and S
- type A has a property 'myAggregationOfB' of type B
- type B has a property 'id'
- type S is an extension of type B with an additional property 'name'
- we consume a webservice with an IN parameter of type A

- during runtime on the axis-client side, we instantiate the
  subclass S and assign it to our instance of A by calling
  A.setMyAggregationOfB(S)

with Axis 1.1, the BeanSerializer generated the following xml
(i adapted it to the above example by hand):

<A> <myAggregationOfB xsi:type="ns1:S" xmlns:ns1="http://somenamespace";> <id>an id</id> <name>a name</name> </myAggregationOfB> </A>

with Axis 1.3, the BeanSerializer generates the following xml
(i adapted it to the above example by hand):

<A> <myAggregationOfB> <id>an id</id> </myAggregationOfB> </A>

As you can see, Axis 1.3 ignores the fact that during runtime,
a subclass of B is present and therefore does not serialize
the additional attributes of the subclass S.

So i researched the cvs repository and found the difference
in the implementation auf the SerializationContext:

Axis 1.1 implementation:

    private void serializeActual(QName elemQName,
                                Attributes attributes,
                                Object value,
                                QName xmlType,
                                Boolean sendType)
    {
        //..
        Class javaType = value.getClass();

Axis 1.3 implementation:

    private void serializeActual(QName elemQName,
                                Attributes attributes,
                                Object value,
                                QName xmlType,
                                Class javaClass,
                                Boolean sendType)
    {
       //...
       Class javaType = getActualJavaClass(xmlType, javaClass, value);

With other words, Axis 1.1 took the runtime java-class in
order to execute the serialization while Axis 1.3 takes the
java-class derived from the wsdl (which is the base-class in
my example).

so i conclude with the following questions:
- is this an Axis bug?
- is there a way to change the behavior i way, that tells
  Axis to serialize the subclasses as it was done by Axis 1.1?
- has anyone else similar problems?

thanks in advance,
Thomas