When it comes to the serializer framework, inheritance can be tricky.
Since you're using the base type in the method signature, Muse is going to
use that type's serializer to try and convert XML -> POJOs. It really has
no other way of knowing what type it should use. If we looked up the
serializer by the QName in the XSD, then you'd have to start declaring
serializers for every parameter type, even the ones that were built-in
(cisco:Name -> StringSerializer, cisco:Port -> IntegerSerializer, etc.).
If we're going on the Java signature alone, then Muse would somehow have
to know all of the concrete sub-types of the base type in order to try and
find serializers for them (the fact that you declare <custom-serializer/>s
for all of them doesn't mean that Muse has th XSD or Java relationships
between them).
I'm willing to have a thread for brainstorming on how we can solve this
problem properly, but for now I think you have to hack around it like so:
public class PropertyNameAndValueTypeSerializer implements Serializer
{
public Class getSerializableType()
{
return PropertyNameAndValueType.class;
}
public Object fromXML(Element xml)
{
QName name = XmlUtils.getElementQName(xml);
SerializerRegistry registry =
SerializerRegistry.getInstance();
Serializer subTypeSerializer = null;
if (name.equals(SUB_TYPE1_QNAME))
subTypeSerializer =
registry.getSerializer(SubType1.class);
else if (name.equals(SUB_TYPE2_QNAME))
subTypeSerializer =
registry.getSerializer(SubType2.class);
...
return subTypeSerializer.fromXML(xml);
}
...
}
"Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 03/19/2007
07:15:14 PM:
> I have an outstanding issue which I haven't found a solution for
> sometime now. Suppose we have these classes:
>
> PropertyNameAndValueType -parent class that stores a String
> name
> PropertyNameAndStringValueType -child class that stores a String name
> and String value
> PropertyNameAndBlobValueType -child class that stores a String name
> and Object value
>
> I have a QueryService resource that defines a Get operation:
> get(String name, PropertyNameAndValueType[] args)
>
> This operation takes in a list of generic PropertyNameAndValueType
> objects, and sub-handlers must cast them to the specific
> *StringValueType or *BlobValueType classes as needed.
>
> On the client side proxy, I am passing an array of specific
> PropertyNameAndStringValueType objects. This gets sent to server ok.
>
> But, the problem is that on the server side, Muse calls my serializer
> for the base PropertyNameAndValueType, which returns these types of
> objects. Down in the sub-handlers layer, I am getting exceptions
> because I can't cast the objects to a specific
> PropertyNameAndStringValueType.
>
> The same design problem occurs when the server sends out generic types,
> and the client needs to cast them to specific types.
>
> What is the proper way to leverage Muse so that operations can define
> generic parameter types, but internal logic can still convert them to
> the specific types?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
