[
https://issues.apache.org/jira/browse/MUSE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495884
]
Vinh Nguyen commented on MUSE-215:
----------------------------------
After further research, this might not be a bug at all, but an intended design
limitation of Muse. My schema above defines a Get operation with a parameter
named "Get_arguments". The parameter type is an array of
PropertyNameAndStringValueTypes. I realize that in this schema, the array name
is the parameter name, but the array elements are not named at all. So the xml
output that I am seeing really is the proper output -- the array elements have
the same name as the array itself.
This follows the Java convention where you can name an array instance (by the
name of the variable used to represent the array), but you can't actually name
each array element. So Muse is following this convention.
But, in a wsdl/xsd, you are allowed to name the array elements, too, like in
this schema:
<xs:element name="Get_arguments">
<xs:complexType>
<xs:sequence>
<xs:element name="ListItem"
type="tns:PropertyNameAndStringValueType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Here, the array name is "Get_arguments", and the array elements are named
"ListItem".
But, Muse uses the least common denominator approach, so during serialization,
it only references the parameter name. So each array element is serialized
using the name of the array itself.
In the generated client proxies, only the request parameter names are stored.
The names of any elements in the parameter itself (ie. array elements) are not
stored. So digging further in the Muse code, ReflectionProxyHandler.toXML()
serializes the array parameter by passing only the parameter name to the
serializer. SerializerRegistry.registerSerializer() only maps an
ArraySerializer instance with the array class of the type to be serialized.
And in ArraySerializer.toXML(), it only has access to the array name.
It would be nice if Muse does support the naming of array elements, but I know
it will take a lot more work to fit this into the current serialization
structure. For now, I realize this is not a bug, and my serializer code
follows the Muse convention for serialization, which compensates for this
limitation.
So I guess it's ok to close this issue, if the Muse team decides that no
further fixes will be made.
> Serializer.toXML() requires unnecessary parent element with specified QName
> ---------------------------------------------------------------------------
>
> Key: MUSE-215
> URL: https://issues.apache.org/jira/browse/MUSE-215
> Project: Muse
> Issue Type: Bug
> Affects Versions: 2.2.0
> Environment: Muse 2.2.0, JDK 1.5.0
> Reporter: Vinh Nguyen
> Assigned To: Dan Jemiolo
> Fix For: 2.3.0
>
> Attachments: TestApp.zip
>
>
> The issue applies to all Muse releases so far.
> I have this Get operation defined as:
> <xs:element name="Get_queryName" type="xs:string"/>
> <xs:element name="Get_arguments"
> type="tns:PropertyNameAndStringValueType"/>
> <xs:element name="Get">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="tns:Get_queryName" minOccurs="1"
> maxOccurs="1"/>
> <xs:element ref="tns:Get_arguments" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The java method is:
> public String get(String queryName, PropertyNameAndStringValueType[]
> queryArgs)
> There is an issue with the Serializer.toXML(Object, QName) method. It
> requires the Element returned to have the QName specified in the parameter.
> This forces my code to create a parent element with that QName, and then set
> the real xml element as the child. This causes an unnecessary xml layer on
> the data, which the fromXML() method must strip away to get at the real data.
> The effect is two problems:
> 1) When an array of PropertyNameAndStringValueType objects is sent, each
> object is wrapped in a parent element with the QName passed into toXML() by
> Muse. The result is no longer a list of PropertyNameAndStringValueType
> objects, but a list of <Get_arguments> objects.
> 2) The dependency on toXML() to add an extra element wrapper and fromXML() to
> strip the wrapper, requires all clients to use the custom serializers.
> Otherwise, if a client sends a properly formatted xml request without the
> unnecessary list wrappers, and the server calls fromXML() to strip expected
> wrappers, data will be lost and errors will occur.
> For example, I expected my client output to have one <Get_arguments>
> containing a list of <PropertyNameAndStringValueType> elements like this:
> <soap:Body>
> <pfx1:Get xmlns:pfx1="http://schemas.cisco.com/Query";>
> <pfx1:Get_queryName>TestQueryName</pfx1:Get_queryName>
> <pfx1:Get_arguments>
> <quer:PropertyNameAndStringValue
> xmlns:quer="http://schemas.cisco.com/Query";>
> <quer:propertyName>PropertyName 1</quer:propertyName>
> <quer:stringValue>String value 1</quer:stringValue>
> </quer:PropertyNameAndStringValue>
> <quer:PropertyNameAndStringValue
> xmlns:quer="http://schemas.cisco.com/Query";>
> <quer:propertyName>PropertyName 2</quer:propertyName>
> <quer:stringValue>String value 2</quer:stringValue>
> </quer:PropertyNameAndStringValue>
> </pfx1:Get_arguments>
> </pfx1:Get>
> </soap:Body>
> But instead, I get one <Get_arguments> containing a list of other
> <Get_arguments> elements:
> <soap:Body>
> <pfx1:Get xmlns:pfx1="http://schemas.cisco.com/Query";>
> <pfx1:Get_queryName>TestQueryName</pfx1:Get_queryName>
> <pfx1:Get_arguments>
> <pfx1:Get_arguments>
> <quer:PropertyNameAndStringValue
> xmlns:quer="http://schemas.cisco.com/Query";>
> <quer:propertyName>PropertyName 1</quer:propertyName>
> <quer:stringValue>String value 1</quer:stringValue>
> </quer:PropertyNameAndStringValue>
> </pfx1:Get_arguments>
> <pfx1:Get_arguments>
> <quer:PropertyNameAndStringValue
> xmlns:quer="http://schemas.cisco.com/Query";>
> <quer:propertyName>PropertyName 2</quer:propertyName>
> <quer:stringValue>String value 2</quer:stringValue>
> </quer:PropertyNameAndStringValue>
> </pfx1:Get_arguments>
> </pfx1:Get_arguments>
> </pfx1:Get>
> </soap:Body>
> Attached is my test program.
--
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]
