Sanjiva/Tony, Thanks for the suggestions, Dave -----Original Message----- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Sunday, July 23, 2006 7:41 AM To: [email protected] Subject: Re: [Axis2] How to perform startup initialization?
On Sat, 2006-07-22 at 15:04 -0400, Dave Cowing wrote: > I'm getting started with Axis 2 and am looking to perform some > initialization when axis2 starts up. Specifically, I'm looking to > configure a database pool and a couple of other resource pools that > will be shared by web services. > > In a servlet, I do this by creating a servlet listener, configuring > the pool objects and dropping them into the servlet context. > > I assume that I should be looking at the Service Group or > Configuration Context to store the pools. I also tried creating an > AxisObserver, but I don't seem to be able to access the contexts. > > How can I create a method that's called when axis2 starts up and has > access to these contexts? The contexts are available only at runtime. I don't think we currently have a defined programming model for system init time, system-wide user code execution. [You're not really a "user" though as you want to do this for a group of unconnected services. (If that were not the case you could use the service lifecycle stuff in a service group.) This is really a system extension point.] There are several work arounds but none are very elegant: - do what Tony suggested: use the services' init() method to create the stuff and push the data into the ConfigurationContext so its visible to all services. You'll need to have the same code in all the services as you (presumably) don't know which one will be used first. - write a module and deploy it globally- this module will then get called and you can do the same as the above but at least you don't have to tell service authors to do any work (except go look up the db pool). If you want a proper first class solution please post a note on the axis-dev list (with [axis2] prefix) and also open a JIRA. Its a useful feature but must be done carefully to avoid risking the system to a malicious or careless service author doing this. Thanks, Sanjiva. --------------------------------------------------------------------- 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]
