Bug 5671

Summary:	Problem with notification message type in ws-rendezvous
Product:	GRAM	Reporter:	Martin Feller <feller@mcs.anl.gov>
Component:	wsrf rendezvous	Assignee:	Martin Feller <feller@mcs.anl.gov>
Status:	RESOLVED FIXED
Severity:	normal	CC:	bacon@mcs.anl.gov, bester@mcs.anl.gov, smartin@mcs.anl.gov
Priority:	P2
Version:	4.1.2
Target Milestone:	4.2
Hardware:	Macintosh
OS:	All

Description From Martin Feller 2007-11-08 16:48:37

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.

------- Comment #1 From Martin Feller 2007-11-08 17:02:34 -------

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)