You've got the two steps exactly right. I think I will take your two steps and some of the other contents of this thread and create another how-to item for the documentation. Thanks!
Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 12/06/2006 03:10:15 PM: > Thanks Dan, > It's clear now. I think I've been confusing myself after looking at so > much stuff lately, that I forgot about the couple lines in > ConsumerCapabilityImpl where it added itself as the message listener. > So receiving notifications is a 2-step process: > > 1) Subscribe a resource to the notification producer. This specifies > the EPR where XML notification messages should be sent to. > 2) The resource that receives the notifications (consumer) must > implement a NotificationMessageListener, which can actually do something > with the messages. The NotificationConsumer object in the consumer > resource manages the message listeners, and will pass messages to the > corresponding listeners when the XML notifications are received. > > For some reason, I got confused and was thinking that the producer > needed to figure out what object to directly invoke in the consumer > resource, in order to pass the notification message to. Not sure why I > was thinking that:) > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 06, 2006 10:49 AM > To: [email protected] > Subject: Re: wsn consumer > > The NotificationConsumer implementation handles the firing of > NotificationMessageListeners for each message received throughthe Notify > operation. These NotificationMessageListener objects can be registered > at any time using the NotificationConsumer's add/removeListener() > methods. > The objects do *not* have to be capability implementations - they just > have to implement the NotificationMessageListener interface. Normal Java > stuff. > > In the wsn-consumer example, there is not much code, so I just made the > capability double as the listener and add itself (addListener(this)). I > could have also created a separate class, instantiated it, and added > that object with addListener(). Either way is fine. For more complicated > listeners, the latter is probably better. > > To make it so that a listener only executes its tasks for a specific > producer, you need to implement the > NotificationMessageListener.accepts() > method such that the producer's EPR is taken into consideration. > Something > like: > > ----------------- start sample code ---------------------- > > public class MyListener implements NotificationMessageListener { > public boolean accepts(NotificationMessage message) > { > EndpointReference producer = > message.getProducerReference(); > // test EPR content to verify producer's identity > } > > public void processMessage(NotificationMessage message) > { > // this is only called if accepts() returns 'true' > } > } > > ----------------- end sample code ------------------------ > > If you are filtering based on producer, I imagine you are going to add > some constructor code that will allow you to tell the object what > producer(s) it is responding to. > > Of course, if you have one WS-resource instance responding to > notifications from multiple resource types, I imagine the topics and > message patterns of the events will be quite different... a more robust > solution might be to filter based on the topics or XPath. Also, since > you can add/remove listeners at any time, you can also create listeners > for a specific subscription, at the time of the subscription: > > ----------------- start sample code ---------------------- > > public class MySubscriptionListener implements > NotificationMessageListener { > private EndpointReference _mySubscription = null; > > public MySubscriptionListener(EndpointReference subscription) > { > _mySubscription = subscription; > } > > public boolean accepts(NotificationMessage message) > { > EndpointReference subscription = > message.getSubscriptionReference(); > return _mySubscription.equals(subscription); > } > > public void processMessage(NotificationMessage message) > { > ... > } > } > > > ... > > > // > // code to make a subscription and then create a listener for it // > > NotificationProducerClient producer = new > NotificationProducerClient(...); SubscriptionClient subscription = > producer.subscribe(...); > > EndpointReference subEPR = subscription.getEndpointReference(); > MySubscriptionListener listener = new MySubscriptionListener(subEPR); > > NotificationConsumer nc = > getResource().getCapability(WsnConstants.CONSUMER_URI); > nc.addListener(listener); > > ----------------- end sample code ------------------------ > > Does this clarify your options? > > Dan > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 12/06/2006 > 03:42:54 AM: > > > In the wsn-consumer example, the code shows how to register a resource > > > as a notification consumer. Then, to receive the notifications, the > > NotificationMessageListener interface must be implemented. In the > > example, this is done by a ConsumerCapabilityImpl capability class > > associated with the "consumer" resource. > > > > My question is: how does Muse know what resource component to call in > > order to pass the notification message? Does it scan thru the > > consumer resource's list of capability classes and invoke the one the > > implements the NotificationMessageListener interface? The muse.xml > > descriptor file doesn't seem to have a place to explicitly tell Muse > > what class to call, but somehow Muse knows already. > > > > So what happens if my resource has 2 capability classes, both of which > > > are NotificationMessageListeners. How does Muse know which one to > call? > > > > There's also the case where each of the 2 capability classes can be > > listening to notifications from different producers (i.e. different > > Muse applications). > > > > > --------------------------------------------------------------------- > 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]
