I'm not sure I understand how the question and the statement are
related... as far as getResource() and AbstractCapability are concerned,
the only requirement on your capability classes is that they implement
org.apache.muse.core.Capability. The AbstractCapability class provides an
implementation of all the "boring" parts of the Capability interface - the
getter/setter methods and the default initialize/shutdown routines (which
are empty). You can certainly create a capability class without it, but
you'll need to fill in all of these methods yourself.
Can you explain your notification issue again? In the sample,
ConsumerCapabilityImpl will be instantiated once for each consumer
resource; there is only one consumer resource created in the current
sample app, but if you added more EPRs to /WEB-INF/classes/router-entries,
you could have more consumer instances. Let me know what you're trying to
do.
Dan
dnguyen <[EMAIL PROTECTED]> wrote on 03/07/2007 05:36:56 PM:
>
> Hi Dan. Is there a way to getResource() without extending
> AbstractCapability? I am thinking that ConsumerCapabilityImpl in
> wsn-consumer sample is instantiated only once, and I need to have
separate
> MessageListener(s) to call NotificationConsumer.addMessageListener()
when
> they get instantiated.
>
>
> Daniel Jemiolo wrote:
> >
> > 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]
> >
> >
> >
>
> --
> View this message in context:
http://www.nabble.com/wsn-consumer-tf2766808.html#a9363921
> Sent from the Muse User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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]
