Hi Dan, I guess it's not necessary to add a new method for automatic serialization of the notification objects. I can always call the following before calling publish(): QName qname = ... Object obj = ... Serializer ser = SerializerRegistry.getInstance().getSerializer(obj.getClass()); Element xml = ser.toXML(obj, qname);
I can put this in a util class and call it from any capability that generates notifications, just to cut down on coding. Now that you bring it up, I've always wondered why the QName object always needs to be specified in Serializer.toXML(Object,QName). Since we don't normally call the Serializer directly, I would assume a custom Serializer already has the responsibility to convert the object to an Element whose top node contains the object's QName. So, if a QName is passed to the toXML() method, does the serializer use that QName for the top node, or override it with it's own QName? And what would be the effect if it did override it? I haven't tried to resolve these questions until now when I have to use the code above to manually serialize an object on my own. I have to figure out what QName to pass, and where to get it from. It gets more complicated when my capability can receive a generic object to publish, so it wouldn't know the QName to use because the logic for that is in the specific serializers. Does this make sense? -Vinh -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Monday, February 12, 2007 9:03 AM To: [email protected] Subject: Re: NotificationProducer.publish with serializable object I found a problem with making the change to publish(QName, Object): because the Serializer API takes a QName (for the name of the root element) and an Object, the publish() method would actually need to look like this: publish(QName topic, QName contentName, Object content); we can't change the existing publish() methods, then, because this would break API compatibility. the only option, then, is to add another overloaded version of publish(), for a total of three. I'm not sure how I feel about this, because it seems kind of bloated. but if it really makes a difference, we'll do it. thoughts? Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 02/08/2007 02:24:15 AM: > The current NotificationProducer has the following two methods: > publish(QName, Element) > publish(QName, XmlSerializable) > > Can an additional method be added to take any type of object, as long > as a Serializer is registered for it? The code should take advantage > of the same Muse serialization engine invoked when a custom object is > returned from a capability method. The new publish() should throw an > error if a non-serializable object is specified. > > This way, we don't need to explicitly serialize our objects to xml > before sending them in a notification, and take advantage of what Muse > can already do for us. Thanks! > -Vinh --------------------------------------------------------------------- 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]
