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]
