Usually I setup an XXXXXApplicationListener in the web.xml that will
initialize things for our app.
Objects/Services can get initialized in multiple ways:
1. Grabbing an instance of a singleton ServiceManager.getInstance();
2. Creating an instance and put it in the ServletContext
If it's application level singleton, I usually do a pattern like:
MenuManager.getInstance(ServletContext ctx) throws ConfigException
{
MenuManager mngr = (MenuManager) ctx.getAttribute(KEY);
if (mngr == null)
{
String source = ctx.getInitParam("menuManagerConfig);
mngr = new MenuManager(source);
ctx.setAttribute(KEY, mngr);
}
return mngr;
}
With additional synchronization, this can assure a single instance gets
created on startup and all application level code can get that instance
without knowing the key it was stored under.
But for lower level stuff like persistence layer stuff that I want to make
sure gets kick started before the first request, I might just make a call to
it or something on the ServletContextListener (XXXXXXApplicationListener).
Regards,
Jacob Hookom
Senior Analyst/Programmer
McKesson Medical-Surgical
-----Original Message-----
From: Robert Taylor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 04, 2004 2:15 PM
To: Struts Users Mailing List
Subject: RE: global data objects -- best practices?
Yes, the ServletContext is the most appropriate place to put it if you
want your data to be available during the life time of the application.
If your container conforms to Servlet spec. 2.3 or higher, a
solution is to implement one or more ServletContextListener(s).
Is the a best practice? I think that may be subjective, but it does
not bind you to any third party solutions.
The container must invoke these upon application start up before it
processes any requests.
For more information refer to the Servlet 2.3 spec or higher.
http://java.sun.com/aboutJava/communityprocess/first/jsr053/index.html
robert
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 04, 2004 3:00 PM
> To: [EMAIL PROTECTED]
> Subject: global data objects -- best practices?
>
>
> hi,
>
> I have a question regarding data objects that should be accessible from
> the entire application and which must be created at container
> startup time.
>
> I need to either create and load an existing index or load a serialized
> index if one exists. This can be a time-consuming process, and I would
> like to do it once when the servlet container starts, then keep the
> index in memory thereafter and available to the entire web application.
>
> I've seen a few different ways of doing this by searching the archives,
> but there wasn't a definitive best practice solution that I came across,
> and the struts API has also changed since many of the suggestions were
> offered.
>
> At present, I am extending the ActionServlet and taking care of the
> initialization stuff in the subclass's init(). I place the generated
> index in the ServletContext. This ensures that the index creation will
> occur only once, at container startup, and that it will be available to
> the action classes of that web application, but I'm not sure if this is
> the best solution. Also, I have just come across plugins for the first
> time, and it seems that they also provide a way of doing
> application-specific initialization. Having the index creation code in
> the ActionServlet, as it is at present, seems messy to me, so perhaps
> that is not the best place for it.
>
> In short, what is the best method for ensuring that a global index is
> created exactly once, and at container startup time? At present, I am
> subclassing ActionServlet, and doing it there, but is the plugin
> mechanism an alternate (better?) solution? Is the ServletContext the
> appropriate place for global data?
>
> thanks in advance,
>
> n.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
