Sounds like this class is loaded in a at least two different class loaders.
Which class loader is the utilitiy class?
I don't know how to answer your question... please expand & I most definitely will answer back =)
Your class loader idea makes it sound as if the jms implementation is not bundled as tightly as it should. It basically kills the possibility of hot-deploying *emergency* patches to a production system.
This has to do with how you package you application. If you deploy a mdb.jar that has the utility class inside of it and you deploy a servlet.war that also has the utility class inside of it, the utility class will be in 2 seperate classloaders which means you will have to versions of the same class runing in your system.
It's all in the packaging, with out details on how you packaged, we can't help you.
You are right, that is the case, our utility classes are packaged in both jar & war. What should I do instead?
Thanks a million.
Your clue was a life-saver today for the same problem with a different scenario: the common/lib/xerces.jar was older that what we're running in jboss/lib/ext.
So is there any clean wasy for me to make sure that all these statics are initialized on a per-class loaded basis? For example my MDB should NOT know what implementation of IApplicationProperties is the current provider of application properties..... the only approach I can think of is the fixed-property file name which internally defines implementation classes a la jdbc driver.