Yes, I think that's the right approach, I just remember there being some other issue. I'll investigate it further and post an update.
Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] "Ramesh Gurunathan" <[EMAIL PROTECTED]> 12/28/2006 12:35 PM Please respond to [email protected] To [email protected] cc Subject Re: Notification Subscriptions If you configure the servlet with "load-on-startup" flag set (in the web.xml), the container will invoke 'init' method of your servlet. Using this mechanism any initialization work can be done more reliably. On 12/29/06, Andrew Eberbach <[EMAIL PROTECTED]> wrote: > This has been an issue with the servlet implementation since the container > doesn't initialize the servet until the first request arrives. > > Thanks, > Andrew > > Andrew Eberbach > Autonomic Computing > (919) 254-2645 > T/L: 444-2645 > [EMAIL PROTECTED] > > > > "Ramesh Gurunathan" <[EMAIL PROTECTED]> > 12/28/2006 12:16 PM > Please respond to > [email protected] > > > To > [email protected] > cc > > Subject > Re: Notification Subscriptions > > > > > > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
