On Sat, 15 Dec 2001 [EMAIL PROTECTED] wrote:
> Date: Sat, 15 Dec 2001 10:05:03 -0800
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Application Design: initialization
>
> Hey All,
>
> I am a bit confused in J2EE (and tomcat) concerning the best spot to
> do a bunch of initializations, and other startup code.
>
> Now, in Coldfusion you have the Application.cfm file which gets run on
> every request, thus you can load up the application scope (if its
> unitialized) or recycle it periodically with data/objects (which is
> great for cache queues).
>
> In jsp, I would like to have a jsp file run on initialization so that
> I can offer that file as a jsp based application initialization file
> (using custom tags to load up the application scope and even session
> and other goodies like internationalization bundles etc).
>
> It seems the best spot would be a ServletContext listener that would,
> on startup, fire a request to the Application.jsp file ... but this
> does not seem possible given the ServletContextListener interface (or
> is it)?
>
> In general, I haven't found much info on best practices for setting up
> the initial state of an application. If I wanted load up some JNDI
> entries on startup, where is the best place to do this (in a
> ServletContextListener perhaps?) ? And for some application
> attributes, same question. And to initialize the session for a user?
>
The JNDI context is read-only from the perspective of the application.
The only way to populate it is in the configuration of your server (for
Tomcat, that means entries in server.xml). See below for a programmatic
alternative.
> I really like the Coldfusion concept of the Application.cfm file since
> you can do all your state checks there, and then all your
> scripts/servlets can expect the web application state to be well
> managed. Its also a great spot for loading in internationalization
> resource bundles.
>
That is exactly what application event listeners are for in the Servlet
API.
> It would be even better to have a more fine grained Application.jsp
> file that would fire on initialization and vice versa, and for a few
> other significant application events. I don't particularly like
> putting a lot of params in the web.xml file since this can complicate
> migrations and makes it a bit un-programmatic. I also like having
> simple custom tags loading the application and session scope so that
> you can glance at one script for the app and see what is in those
> scopes by default, rather than having servlets doing their own thing
> and promoting decentralized scope processes.
>
You're already found the right answer :-)
Servlet context listeners are the correct place to do application-wide
initialization. The contextInitialized() method is called when the
application is first started (or when it is reloaded by the container), so
it is the perfect place to do things like set up resources that must be
present before the first request is processed. Likewise, the
contextDestroyed() method is called at shutdown time, so you can clean up
after yourself.
In a similar manner, you can register listeners for session creation and
destruction, as well as changes to servlet context and session attributes.
However, it's not necessary (or appropriate, IMHO) to embed the
initialization code in a JSP page -- save those for things that need a
user interface. The preferred design pattern is to have your context
listener set up objects (such as connection pools and resource bundles)
and make them available as ServletContext attributes. From the JSP page
perspective, these are just beans in application scope. The page doesn't
have to care how they got there -- thus achieving your goal of separation.
Remember that the event listeners can easily communicate information to
your JSP pages by storing objects in ServletContext scope or Session
scope, as appropriate. It is *not* necessary to use JSP to *create* those
objects.
> Any ideas?
>
> Thanks,
> John.
>
Craig McClanahan
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
