Bugzilla – Full Text Bug Listing
|Summary:||Problem with notification message type in ws-rendezvous|
|Product:||GRAM||Reporter:||Martin Feller <firstname.lastname@example.org>|
|Component:||wsrf rendezvous||Assignee:||Martin Feller <email@example.com>|
|Severity:||normal||CC:||firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
In GT4.2 WSRF will be supported in version 1.2 and WS-Notification in version 1.3. The new notification code (specifically SimpleSubscriptionTopicListener) seems to require that the notification message is of type org.oasis.wsn.NotificationMessageHolderTypeMessage which itself accepts messages of type org.apache.axis.message.MessageElement. Before the specupgrade an arbitrary object was accepted (probably only if an appropriate typeMapping was provided). Java WS Core provides a notification message element of type ResourcePropertyValueChangeNotificationElementType that is not the right type either, but it offers a helper class NotificationTypeConverter that addresses this issue. All services that have different notification messages fail when notifications are to be sent in SimpleSubscriptionTopicListener. WS-Rendezvous is such a service.
Since the notification is triggered manually in ws-rendezvous the same mechanisms like done in Java WS Core for ResourcePropertyValueChangeNotificationElementType could also be applied also to ws-rendezvous. That would mean a transformation of the ws-rendezvous notification message type to a MessageElement using the ObjectSerializer before the notification is initiated in ws-rendezvous. I'll start with that; it may however be better if Java WS Core provided some more flexible handling to allow all kind of notification messages? (because WS-GRAM has the same problem)