One problem with doing initialization on startup is that you have no SOAP/addressing context to work with. This means that rather than using the HTTP or wsa:To header to determine the proper URIs for resource instances, we must piece it together ourselves. This turns out to be a lot of work; after getting the right host or IP address (which we do today), you must also figure out the port, web app name, and whether you need a '/services/' as part of the URI. All without a valid SOAP/HTTP/servlet context (the servlet config data structure you get for init() will not have any HTTP info like the request URI, etc, because there is no request yet).
Additionally, even if we hack around this and create a solution for the mini enviroment, it seems to me that we still have Axis2 to worry about. Dan Andrew Eberbach/Durham/[EMAIL PROTECTED] wrote on 12/28/2006 12:43:48 PM: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
