You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Deepal Jayasinghe (JIRA)" <ji...@apache.org> on 2007/07/18 12:00:30 UTC
[jira] Issue Comment Edited: (AXIS2-2976) 1.3 RC1 BeanUtil changes
cause previously working client to break
[ https://issues.apache.org/jira/browse/AXIS2-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513503 ]
Deepal Jayasinghe edited comment on AXIS2-2976 at 7/18/07 2:58 AM:
-------------------------------------------------------------------
I will not concider this as a bug think about the following scenario where we have following kind of POJO calss
Public class MyService {
int a ;
Man man;
}
In this case what happen if some one send the following request
<MyService>
<a>10</a>
<Man/>
</MyService>
In this case we HAVE to create Man object and the value of that will be assign to default values. So if the element is there in the request then we need to create the object irrespective of whether it has child not or not.
I had to do this changes to fix the issues of ComplexDataTypesComplexDataTypesSOAP11Test
was:
I will concider this as a bug think about the following scenario where we have following kind of POJO calss
Public class MyService {
int a ;
Man man;
}
In this case what happen if some one send the following request
<MyService>
<a>10</a>
<Man/>
</MyService>
In this case we HAVE to create Man object and the value of that will be assign to default values. So if the element is there in the request then we need to create the object irrespective of whether it has child not or not.
I had to do this changes to fix the issues of ComplexDataTypesComplexDataTypesSOAP11Test
> 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