Craig beat me to it :) That's exactly what I was going to say.
One point to make... if you do it with a servlet anyway and you read in
your config and store it in a bean as static members, and one of the
fields you set is a boolean configured field, and only populate the bean
if its false, then the servlet being created and destroyed doesn't
really matter, your code will still work as expected.
Probably a better idea to be more deterministic and do it with a
listener though, for the reasons Craig expertly described.
Frank
Craig McClanahan wrote:
On 8/9/05, Dave Newton <[EMAIL PROTECTED]> wrote:
Frank W. Zammetti wrote:
P.S. - Someone else asked if a listener is better than a startup
servlet of Struts plug-in... IMO, it's better than a plug-in because
it's one less thing that is Struts-specific... Arguably it isn't any
better than a startup servlet I suppose.
I'm still using startup servlets out of habit and was just wondering if
there was any compelling reason to switch over to session listeners--any
differences under clustering or something? I dunno.
On most existing containers it probably doesn't matter, but you are
relying on a non-required-by-the-specs behavior isse when you do this.
(The exact same issue affects Struts plugins, which are managed in
the init() and destroy() methods of ActionServlet.)
The servlet container is *explicity* allowed (if it wants to) to
unload a servlet at any point during the application's lifetime, which
would include a call to destroy(). If a subsequent call for this
servlet comes in, it will get reinitialized via init(). Why might a
container want to do this? Maybe it is seeing memory getting full,
and no calls to your servlet (quite likely if it is solely used for
initialization). Just like an OS might want to swap out an idle
process, the container might want to "swap out" an idle servlet.
If this happens to your initialization servlet, or to the Struts
ActionServlet, this is not likely to be a Good Thing.
A ServletContextListener, on the other hand, is *guaranteed* that the
contextInitialized() and contextDestroyed() methods are only called at
those two points in the application's lifetime, no matter what happens
in between.
Dave
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
