axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-2976) 1.3 RC1 BeanUtil changes cause previously working client to break
Date Wed, 18 Jul 2007 09:44:04 GMT

    [ https://issues.apache.org/jira/browse/AXIS2-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513505
] 

Deepal Jayasinghe commented on AXIS2-2976:
------------------------------------------

s/I will consider/I will not consider

> 1.3 RC1 BeanUtil changes cause previously working client to break
> -----------------------------------------------------------------
>
>                 Key: AXIS2-2976
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2976
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: databinding
>    Affects Versions: 1.3
>         Environment: Linux running Java 1.6, Axis 1.3 RC1
>            Reporter: Sathija Pavuluri
>            Assignee: Deepal Jayasinghe
>
> Certain changes that were made to BeanUtil in adb's databinding package cause my client
to break due to 2 changes.
> The changes were made in revision 546616.
> http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/adb/src/org/apache/axis2/databinding/utils/BeanUtil.java?r1=543752&r2=546616
> Issue 1:
> ------------------------------------------------------------------------------------------------------------
> What the change essentially did from my client's perspective is this:
> ClassA {
>    int i = 0;
>    ClassB b = null;
> }
> When the BeanUtil class serialized this object, the resulting ObjectA's state is like
this:
> ObjectA { i=0; b = ObjectB} as opposed to b=null.
> I hope I made my point clear, when I supply it an object with a field whose value is
null, the resulting object's field is no longer null, but an actual instance is created (always!).
> And here is the change that's doing this (from revision 546616 diff to its previous):
> @@ -363,15 +374,14 @@
>                      PropertyDescriptor proprty = propDescs[i];
>                      properties.put(proprty.getName(), proprty);
>                  }
> -                boolean tuched = false;
>                  Iterator elements = beanElement.getChildren();
> +                if (beanObj == null) {
> +                    beanObj = objectSupplier.getObject(beanClass);
> +                }
>                  while (elements.hasNext()) {
>                      // the beanClass could be an abstract one.
>                      // so create an instance only if there are elements, in
>                      // which case a concrete subclass is available to instantiate.
> -                    if (beanObj == null) {
> -                        beanObj = objectSupplier.getObject(beanClass);
> -                    }
>                      OMElement parts;
>                      Object objValue = elements.next();
>                      if (objValue instanceof OMElement) {
> @@ -405,14 +415,9 @@
>                          if (writeMethod != null) {
>                              writeMethod.invoke(beanObj, parms);
>                          }
> -                        tuched = true;
>                      }
>                  }
> -                if (tuched) {
> -                    return beanObj;
> -                } else {
> -                    return null;
> -                }
> +                return beanObj;
>              }
> See how the variable 'tuched' is no longer used and beanObj is always instantiated  (even
when there is no next element) outside the while loop. 
> This creates objects whose inner references are never going to be null (when they really
may be if the client never populated them).
> Was there any reason that change was made (there was no code comment to suggest that)
? If not, I think that code should be reverted back.
> Issue 2:
> --------------------------------------------------------------------------------------------------------
> From the same diff, notice this change:
> @@ -609,8 +614,12 @@
>                                           helper, true, objectSupplier);
>                  valueList.add(o);
>              }
> -            retObjs[count] = ConverterUtil.convertToArray(arrayClassType,
> -                                                          valueList);
> +            if(valueList.get(0)==null){
> +                retObjs[count] = null;
> +            } else {
> +                retObjs[count] = ConverterUtil.convertToArray(arrayClassType,
> +                        valueList);
> +            }
> Notice how the return array is always created irrespective of the valueList being empty.
> ConverterUtil.convertToArray creates an array object which is null when valueList  is
empty. 
> When my client provides a null array I expect that it  comes out of BeanUtil as null
rather than as a non-null array object with an empty element.
> Again, if this was not done for any good reason, should probably be reverted back.
> Thanks,
> Sathija.

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


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


Mime
View raw message