I think I originally had it as Element because I wanted to stress that it
had to be XML in the absence of javadoc or code-assist. The
XmlSerializable overload still meets this requirement. Still, this is not
totally consistent with other parts of the framework. I suppose what
really needs to be done is to change the API so that there is one method:
publish(QName, Object)
The new object will lookup the Serializer as you described and add the XML
to the message. This should not break existing code because both Element
and XmlSerializable are Objects (duh) and they both have Serializers
(Element serializer is a no-op). I will do a sanity check on this to make
sure no existing code breaks.
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]
