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?
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]
