aspose file tools*
The moose likes Servlets and the fly likes Singleton clash inside web application server? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Singleton clash inside web application server?" Watch "Singleton clash inside web application server?" New topic
Author

Singleton clash inside web application server?

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hello world!
We are writing applications that are deployed on application servers tomcat ,bea weblogic or websphere. The problems come from a generic library we have written to access some common feature like properties , logging or exception management. In these libraries we are using some singletons. Could having multiple web applications deployed on a server give us some problems with our Singletons? In other words do all these web applications run on the same VM?
We think that the answer is Yes. Could anybody confirm this and maybe give a Solution.
thanks all! but please answer!

Laurent Lebrun & Benjamin L�onard
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
The web apps may run in the same VM, but that's not really the issue. Each web application is given a custom classloader instance, and it is this which determines whether to instantiate another copy of your "singleton".
If the classes for your singleton are included in the web application directory (or the war file), then there will probably be a copy for each web app. If the classes for your singleton are loaded externally from the classpath (or the jre/lib/ext directory) then they will probably share the same instance.
Are you really, really sure that these classes need to be singletons. Over-use of the Singleton pattern is one of the most common problems when people first encounter patterns. Can you describe the purpose of the singletons in your system -- what aspect of a logging subsystem needs to be a singleton, for example?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi!
In our common library we have two singletons. the first one is used to created some traces on a file or on the console. The aim of it is to avoid the use of System.out.println and replace it by something like Log.write(.........) which is as simple for the developer and can be configured by addings in a properties file. This singleton instantiates a wrapper of existing log system (like log4J...)and delegates the writing to this. All the log message is centralized and the Log class is instantiated one time.
The other singleton is ProjectProperties which loads (for example from a XML file) the properties and makes it available from all the application.
For now, it seems that we don't have the problems because the jar are not common between the application. But in a close future it will be the case. Can you tell us where we can find a understandable source for classloader in application server?
thanks for you reply!


------------------
Benjamin l�onard
www.evisor.com
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
The usual problem with using the Singleton pattern is that the use of a singleton implies that there will only ever be one instance of whatever is being referred to. This often seems a natural choice, but by choosing to enforce this in your application architecture you lose a lot of flexibility.
For example, consider your logging system. Can you say with your hand on your heart that you will never want to set a different logging policy for just some of the applications in your system? What about debugging a new or changed component? Switching loglevel or log destination globally for all the applications at once seems very clumsy in comparison to the fine grained control you could have if you didn't use a global singleton.
In this case, the web application classloader is your friend. Let it instantiate a new Logging system for each application and you then have full control. If you initialize the system based on a global default properties file, but allow a local override within from the web application, you get the best of both worlds - simple default installation, but power amd flexibility when you need it.
The same logic applies to your global properties. The overhead of a properties object for each web application is very small compared to the flexibility of being able to configure them differently when you need it. And believe me, you will need it, even if only for testing or bug-fixing - you don't want to have to run all your diagnostics against a live database, for example, when you could create a simple one with known data and use that.
Has this helped?
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
hi !
Back on the track!
Originally posted by Frank Carver:
The usual problem with using the Singleton pattern is that the use of a singleton implies that there will [b]only ever be one instance of whatever is being referred to. This often seems a natural choice, but by choosing to enforce this in your application architecture you lose a lot of flexibility.
[/B]

ok we 've well understand this principle
I hope


For example, consider your logging system. Can you say with your hand on your heart that you will never want to set a different logging policy for just some of the applications in your system? What about debugging a new or changed component? Switching loglevel or log destination globally for all the applications at once seems very clumsy in comparison to the fine grained control you could have if you didn't use a global singleton.


Here I don't think we have a problem of flexibility we can configure the loglevel and the medium up to packages and class level, by using Log4j properties file (different for each web application).
It is really a good tool. For the principles, i agree: I lost flexibility.


In this case, the web application classloader is your friend. Let it instantiate a new Logging system for each application and you then have full control. If you initialize the system based on a global default properties file, but allow a local override within from the web application, you get the best of both worlds - simple default installation, but power amd flexibility when you need it.


that's the point!
ok
My problem is to create a properties "dispenser" that can be access either from fix class of a jar files and by specific classes of the applications.
I create this dispenser Classes inside my library jar file it will be unique for the Web-app thanks to the ClassLoader.
This class will load it's basic properties from a property file wich can be in the WEB-INF/lib/library.jar or in the WEB-INF/classes (if we want to read this first).
with this i hope i understand the principle! I have to test now....


Has this helped?

thanks for all.
You open the window of classsloader that we didn't see well


------------------
Benjamin l�onard
www.evisor.com
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Singleton clash inside web application server?