[
https://issues.apache.org/jira/browse/AXIS2-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514226
]
Sathija Pavuluri commented on AXIS2-2976:
-----------------------------------------
Deepal,
I created a service just like the one you have above and used the same POJOs
and retested with 1.3 RC2.
The only difference is that I did not generate the stub.
I instead use a Impl and Stub that I wrote manually.
public class ManServiceImpl extends ManService {
public Man setValue(Man test) throws Exception{
return test;
}
}
public class ManServiceStub extends ManService {
private RPCServiceClient serviceClient = null;
ManServiceStub(RPCServiceClient serviceClient) {
this.serviceClient = serviceClient;
}
public Man setValue(Man test) throws Exception{
QName operation = new QName("http://service.ws.test.com/xsd";,
"setValue");
Object[] args = new Object[] {test};
Class[] returnTypes = new Class[] {Man.class};
Object[] response = serviceClient.invokeBlocking(operation,
args, returnTypes);
Man result = (Man) response[0];
return result;
}
}
And invoke the service this way in my test class:
Man man = new Man();
man.setA(10);
Man returned_man = ManService.setValue(man);
Here is the request/response:
Request
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Body>
<setValue xmlns="http://service.ws.ena.emprisa.com";>
<arg0 xmlns="" type="com.emprisa.ena.dto.Man">
<a>10</a>
<address xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:nil="true" />
</arg0>
</setValue>
</soapenv:Body>
</soapenv:Envelope>
Response
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Body>
<ns:setValueResponse xmlns:ns="http://service.ws.ena.emprisa.com";>
<ns:return xmlns:ax28="http://dto.ena.emprisa.com/xsd";
type="com.emprisa.ena.dto.Man">
<ax28:a>10</ax28:a>
<ax28:address type="com.emprisa.ena.dto.Address">
<ax28:number xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:nil="true" />
<ax28:street xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:nil="true" />
</ax28:address>
</ns:return>
</ns:setValueResponse>
</soapenv:Body>
</soapenv:Envelope>
Notice that the request has address as null, however the response does not.
My service impl does not manipulate any object , just returns the object it
receives.
I retested the same service with a 1.2 distribution and I see this request and
response :
Request
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Body>
<setValue xmlns="http://service.ws.ena.emprisa.com/xsd";>
<arg0 xmlns="" type="com.emprisa.ena.dto.Man">
<a>10</a>
<address xmlns:nil="http://www.w3.org/2001/XMLSchema-instance";
nil:nil="true" />
</arg0>
</setValue>
</soapenv:Body>
</soapenv:Envelope>
Response
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Body><ns:setValueResponse
xmlns:ns="http://service.ws.ena.emprisa.com/xsd";>
<ns:return type="com.emprisa.ena.dto.Man">
<a xmlns="http://dto.ena.emprisa.com/xsd";>10</a>
<address xmlns="http://dto.ena.emprisa.com/xsd";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"
/></ns:return>
</ns:setValueResponse>
</soapenv:Body>
</soapenv:Envelope>
As you can see, the response is correct in this case i.e address is null.
Now I am not sure what's causing this discrepancy. something in BeanUtil's
de-serialization?
> 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]
