[
https://issues.apache.org/jira/browse/AXIS2-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514274
]
Sathija Pavuluri commented on AXIS2-2976:
-----------------------------------------
I've done some more testing using the generated code as you did and that did
not reproduce the problem.
The generated stub has code that correctly serializes and then parses the xml.
That explains why you see the correct request response.
So in order to reproduce the problem that I am seeing you need to use manually
coded Stub.
Please use the attached src.
Thanks,
Sathija.
> 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
> Priority: Blocker
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
