[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-user
Subject:    RE: Where should I put my initialization code?
From:       "Steve Brewin" <sbrewin () synsys ! com>
Date:       2008-02-16 18:19:59
Message-ID: 000601c870c8$8b440500$0901a8c0 () synsys ! com
[Download RAW message or body]

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: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]