axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Lavelle (JIRA)" <axis-...@ws.apache.org>
Subject [jira] [Commented] (AXIS-2383) Is this a serialization bug introduced in axis 1.3?
Date Fri, 05 Aug 2016 15:15:20 GMT

    [ https://issues.apache.org/jira/browse/AXIS-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15409566#comment-15409566
] 

Shawn Lavelle commented on AXIS-2383:
-------------------------------------

[~wdeng] Can this be closed?

> Is this a serialization bug introduced in axis 1.3?
> ---------------------------------------------------
>
>                 Key: AXIS-2383
>                 URL: https://issues.apache.org/jira/browse/AXIS-2383
>             Project: Axis
>          Issue Type: Bug
>          Components: Serialization/Deserialization
>    Affects Versions: 1.3
>         Environment: Dell Station, W2000, WSAD 5.1.2, Websphere
>            Reporter: Weian Deng
>            Assignee: Jongjin Choi
>            Priority: Critical
>
> We are working in a project that try to migrate our
> web services from axis 1.1 to axis 1.3 where we found
> a potential bug in SerializationContext that is
> introduced after axis 1.2. 
> Given the following scenario:
> 1. Define a complex type AbstractType,
> 2. Define two complex types ConcretType1 and
> ConcretType2 which extend type AbstractType
> 3. Define complex type D that contains an element E of
> type AbstractType
> E can be assigned an element of type ConcretType1 or
> ConcretType2.
> Serializing an Object of type D that contains an
> element E of type ConcretType1 should use the
> serializer for ConcretType1 to serialize element E.
> This is the behavior on axis 1.1.  But Axis 1.3 uses
> the serializer for AbstracType to do the serialization
> which I think is a bug.  
> Or, is there any setup parameter that can change this
> serialization behaviors?
> After checking the source code of
> SerializationContext. 1.3 introduced a new method
> getActualClass().  The logic there doesn't take care
> of the case that if clz is a sub-class of javaType, we
> should return clz.
> 	private Class getActualJavaClassBug(QName xmlType,
> Class javaType, Object obj) {
> 		Class cls = obj.getClass();
>         
> 		if ((xmlType != null 
> 					&&
> Constants.isSchemaXSD(xmlType.getNamespaceURI()) &&
> "anyType".equals(xmlType.getLocalPart()))
> 				|| (javaType != null 
> 						&& (javaType.isArray() || javaType ==
> Object.class))) {
> 			return cls;
> 		}
>         
> 		if (javaType != null && cls != javaType &&
> !cls.isArray()) {
> 			return javaType;
> 		}
>         
> 		return cls;
> 	}
> Should the second if statement rewrite as follows:
> 		if (javaType != null &&
> !(javaType.isAssignableFrom(cls)) && !cls.isArray()) 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message