Thanks Dan, sounds good to me:) -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Monday, February 12, 2007 11:29 AM To: [email protected] Subject: RE: NotificationProducer.publish with serializable object
The QName is needed for the root element in the fragment, which is sometimes the only element. For primitive types and String/URI/QName/etc., you need an element name to make the fragment: <WhatIsThisValue>1234</WhatIsThisValue> Additionally, for complex types, you often need to control the name of the root element. EPRs are a great example. The wsa:EndpointReference type is extended in many WS-* specs simply by changing the name of the EPR element. Examples are wsnt:SubscriptionReference and wsrf-sg:MemberEPR. The serializer can't always create the right fragment (or even a valid fragment) if it doesn't know what you want the name of the root element to be, so that's why it's part of the API. We can add the extra publish() method (with the three params), I was just asking if anyone had a strong like/dislike of the idea... Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 02/12/2007 01:47:18 PM: > 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] > --------------------------------------------------------------------- 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]
