Thank you all. It works. But...
When the server restarts it doesn't initialize the capabilities
immediately instead it waits for the first SOAP request to arrive and
then wakes up to initialize the capabilities. When I observed it, the
Mini Servlets doPost method initializes the MiniIsolationLayer... That
means if any event occurs before any SOAP request it will not be
published to the consumers, because the notification producer
capability is not initialized yet.
Why the initialization code is placed in doPost? Are there any reasons
for not placing it in the init() method of the servlet?
Appreciate your response.
Thanks again,
Ramesh
On 12/18/06, Daniel Jemiolo <[EMAIL PROTECTED]> wrote:
In addition to the router persistence that has already been mentioned, add
this to muse.xml - this provides the persistence for the actual
subscription data, not just the resource's EPR.
<capability>
<capability-uri>
http://docs.oasis-open.org/wsn/bw-2/NotificationProducer
</capability-uri>
<java-capability-class>
org.apache.muse.ws.notification.impl.SimpleNotificationProducer
</java-capability-class>
<persistence>
<!-- saves the actual subscription data, not just the EPR -->
<java-persistence-class>org.apache.muse.ws.notification.impl.NotificationProducerFilePersistence</java-persistence-class>
<!-- the location can be any directory name -->
<persistence-location>subscriptions</persistence-location>
</persistence>
</capability>
"Grady, Brendan \(Mission Systems\)" <[EMAIL PROTECTED]> wrote on
12/18/2006 09:18:11 AM:
> The class that implements persistence is defined in the deployment
descriptor
> (muse.xml).
>
> <router>
> ...
> <persistence>
> <java-persistence-class>org.apache.muse.core.routing.
> RouterFilePersistence</java-persistence-class>
> <persistence-location>router-entries</persistence-location>
> </persistence>
> ...
> </router>
>
> This specifies the class RouterFilePersistence (extendable and
replacable if
> something more robust is required) as the means to persist resources.
This
> particular implementation writes an xml file to the router-entries
directory
> under /WEB-INF/classes for each subscription.
>
> If you want a particular resource to be persistant, use the 'use-router-
> persistence="true"' tag.
>
> So, if you want to persist your SubscriptionManager Resource entries
(i.e. the
> subscriptions) so that if the server is shutdown/restarted, your
subscriptions
> are reinitialized upon producer startup, edit muse.xml to include the
use-
> router-persistence tag.
> ...
> <resource-type use-router-persistence="true">
> <context-path>SubscriptionManager</context-path>
> <wsdl>
> ...
>
> See http://issues.apache.org/jira/browse/MUSE-44?page=all for Dan
Jemiolo's
> explanation of how RouterFilePersistence.
>
> Also, further explanation on persistence available in the Deployment
Descriptor docs:
>
http://ws.apache.org/muse/docs/2.0.0/manual/architecture/deployment-descriptor.html
>
>
> -----Original Message-----
> From: José Antonio Sánchez [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 18, 2006 2:51 AM
> To: [email protected]
> Subject: Re: Notification Subscriptions
>
> As subscriptions are WS-Resources, then if you define a persistence
method for
> that resources they should be saved to some kind of storage and loaded
when
> server is restarted. But I'm not a Muse developer so I don't know for
sure.
>
> On 12/18/06, Ramesh Gurunathan <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Is it possible to subscribe to a Topic that is durable? What will
> > happen to a subscription in the event of server crash or an intended
> > shut-down? When the server restarts, would it lose all the
> > subscription data?
> >
> > Since the producer/consumer message exchanges are basically
> > asynchronous in nature, it is very difficult for the client
> > applications to know that its subscription is still active and valid.
> >
> > How to handle such situations? Would the restarted server explain all
> > the subscribers about the sudden or intended death that expired all
> > the subscriptions? I don't like the idea of polling the server to
> > check if the server is still alive and therefore the I believe that I
> > will receive notifications.
> >
> > If the durable subscription isn't possible in Muse, how about adding
> > custom codes? Any suggestions please?
> >
> > Ramesh
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Saludos.
> José Antonio Sánchez
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
