[
https://issues.apache.org/jira/browse/AXIS2-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593315#action_12593315
]
Detelin Yordanov commented on AXIS2-3651:
-----------------------------------------
Hello guys,
I'm not sure that I am correct about this but I think there might be a
problem with this.
Suppose we have a service operation that returns the response above. What will
happen if this service is invoked with the
RPCServiceClient, e.g.
RPCServiceClient sender = getRPCClient("WeatherService", "getWeather");
OMElement response = sender.invokeBlocking(new
QName("http://service.pojo.sample";, "getWeather", "req"), new Object[]{});
Weather weather = (Weather)BeanUtil.deserialize(Weather.class,
response.getFirstElement(), new DefaultObjectSupplier(), null);
The BeanUtil.deserialize(..) currently checks for "type" attribute and assumes
that if present it will contain the Java class name, not the schema
name of the type.
If you switch to xsi:type containing e.g. "ax21:Weather" (in the case when the
type table on the server side is not null),
then the BeanUtil.deserialize(..) will fail since it will not have the type
table (it's being called on the client side) and could not find
the Java class mapping for the "ax21:Weather".
I've taken the example above from the org.apache.axis2.rpc.RPCCallTest from the
axis2-integration module.
Regards,
Detelin
> BeanUtil class should try and fill the xsi:type attribute with value from
> type table before defaulting to class name
> --------------------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-3651
> URL: https://issues.apache.org/jira/browse/AXIS2-3651
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: databinding
> Affects Versions: 1.4, 1.3
> Environment: Windows XP SP2, Java 6
> Reporter: Aaron Gourley
> Assignee: nadir amra
> Priority: Minor
>
> Using the type table to fill the xsi:type attribute would help make it
> possible to successfully validate SOAP response messages against the WSDL.
> Although the class name approach may be sufficient for POJO services, it
> provides meaningless information when other approaches are used.
> I suggest replacing the following lines of BeanUtil.java
> // Added objectAttributes as a fix for issues AXIS2-2055 and
> AXIS2-1899 to
> // support polymorphism in POJO approach.
> // For some reason, using QName(Constants.XSI_NAMESPACE, "type",
> "xsi") does not generate
> // an xsi:type attribtue properly for inner objects. So just
> using a simple QName("type").
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName("type"));
> objectAttributes.add(beanObject.getClass().getName());
> With this (or similar ... not sure if qualified check should be there):
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName(Constants.XSI_NAMESPACE, "type",
> "xsi"));
> if( typeTable != null && qualified )
> {
> QName qNamefortheType =
>
> typeTable.getQNamefortheType(beanObject.getClass().getName());
> if (qNamefortheType == null) {
> // Added objectAttributes as a fix for issues AXIS2-2055
> and AXIS2-1899 to
> // support polymorphism in POJO approach.
> objectAttributes.add(beanObject.getClass().getName());
> }
> else
> {
> objectAttributes.add(qNamefortheType);
> }
> }
> else
> {
> objectAttributes.add(beanObject.getClass().getName());
> }
> Note that I had no issues with generating the xsi:type attribute for inner
> elements in my testing (as was mentioned by the existing comment).
--
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]
