Just out of curiosity, what are the drawbacks to implementing a singleton with a static variable (and private constructor, etc)? then there will be only one per classloader, and you still have full control over it's lifecycle, you can remove it with a ServletContextListener (assuming you implemented a static "removeInstance()" method)
On Thursday, June 5, 2003, at 02:12 PM, 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.
Markus
Brian Kidney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
If I have a class in my application which is a singleton, is there only one object per server (Tomcat in my case), or is it unique to the session (ie. each user gets a different instance)?
Brian
-----BEGIN PGP SIGNATURE----- Version: PGP 8.0
iQA/AwUBPt92MuLP0vXx30WgEQKtFQCfX4gkSYSwqx9+Zij4IfQU9DxA6L4An2gY hUqwLgvXo/4W5scinkxmIF7j =Osto -----END PGP SIGNATURE-----
--------------------------------------------------------------------- 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]
