axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From françois françois <fv...@yahoo.fr>
Subject Re: Is this a serialization bug introduced in axis 1.3?
Date Fri, 27 Jan 2006 07:50:10 GMT
Hi , this bug was reported:
   
  http://issues.apache.org/jira/browse/AXIS-2280?page=comments#action_12363513 ] 
   
  i propose one solution see it below , anyone to test it?:
   
   
    I find where it happens in:
  package org.apache.axis.encoding;
  
in  public class SerializationContext 
  when  public void serialize(QName elemQName,
                          Attributes attributes,
                          Object value,
                          QName xmlType,
                          Boolean sendNull,
                          Boolean sendType)
        throws IOException 
    {
        serialize(elemQName, attributes, value, xmlType, null, sendNull, sendType);//here
is problem
        
    } is called ,
  
The function serialize calls :
  void serializeActual(QName elemQName,
                                Attributes attributes,
                                Object value,
                                QName xmlType,
                                Class javaClass,
                                Boolean sendType)
   
  javaClass is always null so when getActualJavaClass  look at the code of :
   
   priva te Class getActualJavaClass(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;
    }
   
  it always return cls so i join my solution with it,you need to add in  the function serializeActual
some codes :
   
   private void serializeActual(QName elemQName,
                                Attributes attributes,
                                Object value,
                                QName xmlType,
                                Class javaClass,
                                Boolean sendType)
        throws IOException
    {
        boolean shouldSend Type = (sendType == null) ? shouldSendXSIType() :
            sendType.booleanValue();
          if (value != null) {
            TypeMapping tm = getTypeMapping();
              if (tm == null) {
                throw new IOException(
                        Messages.getMessage("noSerializer00",
                                             value.getClass().getName(),
                                             "" + this));
            }
              // Set currentXMLType to the one desired one.
            // Note for maxOccurs usage this xmlType is the
            // type of the component not the type of the array.
            currentXMLType = xmlType;
              // if we're looking for xsd:anyType, accept anything...
            if (Constants.equals(Constants.XSD_ANYTYPE,xmlType)){
                xmlType = null;
                shouldSendType = true;
            }
              // Try getting a serializer for the prefered xmlType
            QNameHolder actualXMLType = new QNameHolder();
   
               ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
          
            //here is my fix for bugs if not javaClass was always null
           javaClass=value.getClass();
           Class javaType = getActualJavaClass(xmlType, javaClass, value);

            /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
 
                    
            
           Serializer ser = getSerializer(javaType, xmlType,
                                           actualXMLType);
              if ( ser != null ) {
                // Send the xmlType if indicated or if
                // the actual xmlType is different than the
                // prefered xmlType
                if (shouldSendType ||
                    (xmlType != null &&
                     (!xmlType.equals(actualXMLType.value)))) {
                      if(!isEncoded()) {
                        if (Constants.isSOAP_ENC(actualXMLType.value.getNamespaceURI())) {
                            // Don't write SOAP_ENC types (i.e. Array) if we're not using
encoding
                        } else if (javaType.isPrimitive() && javaClass != null &&
JavaUtils.getWrapperClass(javaType) == javaClass) {
                            // Don't write xsi:type when serializing primitive wrapper value
as primitive type.
                        }
                        else {
                            if(!(javaType.isArray() && xmlType != null &&
Constants.isSchemaXSD(xmlType.getNamespaceURI())) ) {
                                writeXMLType = actualXMLType.value;
                            }
                        }
                    } else {
                        writeXMLType = actualXMLType.value;
                    }
                }
                  // -----------------
                // NOTE: I have seen doc/lit tests that use
                // the type name as the element name in multi-ref cases
                // (for example <soapenc:Array ... >)
                // In such cases the xsi:type is not passed along.
                // -----------------
                // The multiref QName is our own fake name.
                // It may be beneficial to set the name to the
                // type name, but I didn't see any improvements
                // in the interop tests.
                //if (name.equals(multirefQName) && type != null)
                //    name = type;
                ser.serialize(elemQName, attributes, value, this);
                return;
            }
            throw new IOException(Messages.getMessage("noSerializer00",
                    value.getClass().getName(), "" + tm));
        }
        // !!! Write out a generic null, or get type info from somewhere else?
    }


   
  

Jongjin Choi <jongjin.choe@gmail.com> a écrit :
  Weian,

Can you upload the WSDL to JIRA?

/Jongjin

On 1/26/06, Weian Deng wrote:
> Hi, Jongjin,
>
> JIRA Issue AXIS-2383 created. How soon can the issue
> be resolved?
>
> Thank you!
>
> Weian
>
> --- Jongjin Choi wrote:
>
> > Hi, Weian.
> >
> > Can you register it to JIRA?
> >
> > I'd lilke you to upload the test case and proposed
> > patch that you sent
> > me to my private mail.
> >
> > Thanks.
> >
> > On 1/25/06, Weian Deng wrote:
> > > Hi, there,
> > >
> > > 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.
> > >
> > > Weian
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > > http://mail.yahoo.com
> > >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
  


		
---------------------------------
 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.
Mime
View raw message