Thanks Dan, I had suspected that I needed to go that route since I don't see any way for Muse to know what type of object the xml should correspond to, except by looking at the parameter type in the Java method signature and calling the appropriate serialize for that type.
For now, similar to your code below, I'm doing explicit checks in the PropertyNameAndValueTypeSerializer to see if I can convert the xml to the more appropriate type. -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 4:55 PM To: [email protected] Subject: Re: serialization of generic and specific types 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
