Why not keep the ConsumerCapability that's in wsn-consumer today and have
it add all the MessageListeners that you've created? For example, if you
had three MessageListener classes, each of which responded to a different
type of notification, you could do the following:
public class ConsumerCapabilityImpl
extends AbstractCapability implements ConsumerCapability
{
public void initialize()
throws SoapFault
{
super.initialize();
NotificationConsumer wsn =
getResource().getCapability(WsnConstants.CONSUMER_URI);
wsn.addMessageListener(new ListenerClass1());
wsn.addMessageListener(new ListenerClass2());
wsn.addMessageListener(new ListenerClass3());
}
}
So, ConsumerCapability would have no properties or operations, but still
serves an important function in your resource definition. You might want
to change the name to clarify its purpose.
Dan
dnguyen <[EMAIL PROTECTED]> wrote on 03/07/2007 06:06:06 PM:
>
> What I am trying to do is for a given resource deployment (wsn-consumer
for
> example) I need to have varied number of MessageListeners. Since
> ConsumerCapabilityImpl is the only MessageListener, I pulled the
> MessageListener into a separate class, so multiple instances can be
created
> based on other events occuring outside Muse. This lead me to the
> MessageListener class needing to get a hold of the resource's
> NotificationConsumer capability to call addMessageListener(). There
does
> not seem to be a way through the Muse API to do so. It seems I may have
to
> resort to a Singleton to get hold of it. Is this a correct assumption?
>
>
> Daniel Jemiolo wrote:
> >
> > 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]
> >
> >
> >
>
> --
> View this message in context:
http://www.nabble.com/wsn-consumer-tf2766808.html#a9364550
> 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]
