Hi
yes I find the same problem , you need to add the following few lines in the function serializeActual
package org.apache.axis.encoding;
private void serializeActual(QName elemQName,
Attributes attributes,
Object value,
QName xmlType,
Class javaClass,
Boolean sendType)
throws IOException
{***********
Attributes attributes,
Object value,
QName xmlType,
Class javaClass,
Boolean sendType)
throws IOException
{***********
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//here is my fix for bugs if not javaClass was always null
javaClass=value.getClass();
Class javaType = getActualJavaClass(xmlType, javaClass, value);
//here is my fix for bugs if not javaClass was always null
javaClass=value.getClass();
Class javaType = getActualJavaClass(xmlType, javaClass, value);
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
******
otherwise javaClass is always null....
[ http://issues.apache.org/jira/browse/AXIS-2383?page=all ]
Jongjin Choi reassigned AXIS-2383:
----------------------------------
Assign To: Jongjin Choi
> Is this a serialization bug introduced in axis 1.3?
> ---------------------------------------------------
>
> Key: AXIS-2383
> URL: http://issues.apache.org/jira/browse/AXIS-2383
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> 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 ((x mlType != 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 is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez la version beta.
