> Subject: Re: Shared objects for all Servlets - Servlet Initialization
Craig McClanahan:
> Slava Kozlov wrote:
>
> > > Kenneth,
> > >
> > > In a project I'm working on, we used the ServletContext to hold this
> > > information as you said. To get this information loaded at
> > > initialization time, we defined an initialization servlet and set it to
> > > be preloaded. After that, all global objects were ready and available
> > > for us to use.
> > >
> > > bab
> > >
> >
> > Do you also save state when the ServletContext (ie, web application) dies
> > (servlet engine goes down, etc), using the initialization servlet?
> >
>
> I do this kind of state saving in the destroy() method of my
> initialization servlet, and
> rely on the servlet engine not to throw it out during normal running
> -- which it is
> allowed to do. This is a workaround until the servlet API supports
> for-real application
> start and application end events that you can attach this kind of code to.
>
>
Yes. Perfect. I did the same. And called it, PersistenceServlet (or
MyAppPersistenceServlet). And it has a reference to a MyAppServletContext (see
further below) which was a singleton (see below).
> Note that the Singleton pattern does not solve the state-saving issue either.
>
> It also fails horribly if you are running more than one app in the
> same server, and they
> both need the same Singleton class.
Oh, I didn't take the Singleton pattern (in GoF) literally. :-) It's much more
useful to have multiple singletons of different _types_ than one monolithic
Singleton (maybe I'm doing it wrong). Now that I think of it, I don't think i've
ever even made a Singleton interface or abstract class, just (1) made the
constructor private, (2) static factory method and (3) assure single
instantiation. Multiple singletons (whatever you may need them for): type-safety
and uniqueness.
> There is an instance of
> ServletContext per web application, so you do not run into this problem.
>
> Craig McClanahan
A few months ago I had a project where the servlet engine didn't implement JSDK
2.1. Seeing JSDK 2.1's ServletContext on the horizon (and realizing it was a
better architecture for handling application-wide data than servlets talking to
each other directly), I had to implement the ServletContext design myself. It
was a bit of a pain at first, but one uses a MyAppPersistenceServlet to get
things going (as Brian Button (aka bab) suggests); it has a MyAppContext object
(= a singleton hashtable) to store name/value pairs; a wrapper/mediator class to
decouple references to the context (one uses MyAppContextWrapper.getContext()).
The wrapper isn't purely necessary but since, as I mentioned, the intent was to
move to JSDK 2.1, it wouldn't do to litter the code with
getServlet("MyAppPersistenceServlet").getContext() statements all over the
place.
Ok, here's a question: I haven't read the 2.2 spec (nor hints about what may
follow) that thoroughly, but what types of precautions should we (app writers)
make now in order to (1) prevent our current code from simply breaking and (2)
to preemptively design for future enhancements?
Wow, we're still on subject! :-)
-s
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
