On Thu, 5 Jun 2003, Erik Price wrote:
> Date: Thu, 05 Jun 2003 15:10:26 -0400 > From: Erik Price <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: Re: Singletons in Tomcat > > > > Markus Holzem wrote: > > I usually story Singletons in the ServletContext which is unique for > > an application. I often think that ServletContext should be better > > named ApplicationContext because that is actually what it represents. > > > > I don't feel comfortable to leave Singletons hanging around on static. > > variables. The benefit of ServletContext is, that you can easily > > participate on the lifecycle of the ServletContext > > (ServletContextListener::contextInitialized and ~::contextDestroyed) > > and take appropriate actions when your Singleton acquires any system > > resources. > > That's a good point, but even better (IMHO), if your model does not use > any controller-specific resources (makes for easier unit testing too), > is to combine the two. In other words, *do* use the traditional > Singleton on a static variable, but also *do* provide a static method > for destroying the singleton which is then called by the > contextDestroyed method. > There's a tradeoff, of course, for using ServletContext attributes for application scope singletons -- you have to have an instance of the appropriate ServletContext object in order to retrieve that attribute. Among other things, this ties your business classes to operating only in a web application. The general J2EE platform answer to this is the JNDI naming context that is provided by the container. Essentially, this acts like a singleton implemented as a static, and doesn't require access to any objects that tie you to the servlet API. On the other hand, you have to be operating inside an app server environment that provides the JNDI services for you. > I just thought of that now so there could be repercussions I hadn't > considered. > > > > Erik Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
