I have an issue where I am using a Singleton class to manage my properties for a custom application. However if I create two instances of my app, the static value for second instance overwrite that of first instance..... (as expected I suppose..)
Is there any way I can use two instances together?
Has anyone solved a similar problem before?
If possible, I don't want to rewrite code to pass a non-static Properties object throughout all classes. Doesn't anyone know if I use different class loaders for each instance would it work?
I have written a simple application to write message to a MQ Message Server. I initialise application with a Properties object.. some psuedo code.... Similarily to receive a message I have simple code:
In case a above, instance work fine together however .....
.. breaks because sender properties have been over written.....
Please advise..... Any suggestions really appreciated
The men of Ireland were hurling when the gods of Greece were young
Using separate ClassLoaders per sub-application within an application can resolve such problems. However, it is quite hard to get it right. If the sub-applications have to communicate directly via Javaat all, it gets even harder.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
The reason I asked the initial poster to get familiar with the classloading hierarchy is mentioned by Peter Chase.
For example , If you have a singleton class and its being used as part of four web applications and all of them are deployed in Tomcat and the class file of the singleton is present in the lib directory of all the web applications then the class would be loaded four times using webapp classloader of Tomcat and hence no issues.
I do not have any idea about MQ Message server.But in case of EJB deployed in clustered environment (thought not directly related to the actual question) singleton should be avoided.
If possible, I don't want to rewrite code to pass a non-static Properties object throughout all classes.
I would highly recommend to consider this option. It might look like a lot of work, but I seriously think that it is the option that
- is the easiest to understand - is the one with lowest risk of introducing hard to find and fix bugs, and - gives you the most flexibility in the future
The last point is not to be underestimated. Changes tend to cluster - if you now have to do a change for which the Singleton is making things harder, it's likely that it will happen again in the future. Better get rid of it immediately.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stinging nettles are edible. But I really want to see you try to eat this tiny ad: