Martijn Brinkers wrote on 16 February 2008 12:10: > Hi, > > The complicating factor is that I would like to be able to > specify which > resources, for example hibernate config file, should be used during > initialization. This makes it easier for me to use different settings > for normal runtime and testing. Preferably these settings should > specified in confix.xml. My current approach using a James 'service' > seems to be working nicely because it allows me to specify > the settings > in just one place. Although it is kind of similar to having one > initialization mailet I think this approach is better because > it's much > more clear. Is there a compelling reason not to create my own James > service for this?
This is fine as long as you are happy binding your Mailet implementation to the current Avalon infrastructure used by James. This may change in the future. I guess you can worry about it when and if it occurs. -- Steve > Thanks > > Martijn Brinkers > > On Fri, 2008-02-15 at 21:22 +0000, Steve Brewin wrote: > > One solution is to use lazy initialization. Options include... > > > > 1) Initialize early: > > > > Have the Mailet.init() method invoke a Factory object that > checks if the > > resource is initialized. If it isn't, it initializes the > resource and saves > > it before returning the newly initialized object. If it is, > it returns the > > previously initialized and saved object. The returned > object is saved by the > > Mailet.init() method as an instance for use by the > Mailet.service() method. > > > > The Mailet.service() method uses the object instance saved by the > > Mailet.init() method. > > > > The Mailet.destroy() method calls the Factory to tear down > the resource > > which the Factory will do if it hasn't already been torn down. > > > > 2) Initialized on demand: > > > > The Mailet.init() method does nothing. > > > > The Mailet.service() method calls the Factory described in > (1) each time it > > is invoked to obtain the initialized object. Initialization > will occur on > > the first call, thereafter the already initialized object > will be returned. > > > > The Mailet.destroy() method is the same as (1). > > > > > > For heavyweight resources and those with a potential for > failure I prefer > > (1) as the costs and risks are resolved before we start > servicing requests. > > For others I prefer (2), but either is fine. > > > > > As an experiment I added my own 'service' to assembly.xml which is > > > configured upon startup (the service implements > Configurable). This > > > seems to be working but somewhere on the WIKI I read that this > > > functionality will be 'removed' by giving mailets their own > > > classloader. > > > > AFAIK a separate class loader isn't happening anytime soon, > though others > > may correct me. You could wrap your service acquisition in > the Factory > > described above so that how a resource is obtained is > insulated from the > > mailets that use it. Then just the Factory needs to change > if your resource > > management approach changes. > > > > I hope this helps. > > > > -- Steve > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
