Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Singleton clash inside web application server?

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic