I'm struggling with this problem myself - singletons,
Weblogic to JBoss migration, startup classes.
As far as I know, MBeans are loaded in a separate class
loader from EJBs and the two are not directly accessible
from each other. So if you call getInstance() from an
MBean, and then from an EJB, on what's apparently the same
class, you're actually getting two different classes,
separately loaded, each in a different class loader, and so
you end up creating two instances of the singleton.
It's illegal to access static class data from within an
EJB, and this is the reason why - things like singletons
are only unique within the classloader in which the class
I have the same problem - singletons referenced within the
EJBs that I'm porting. Not sure how I'm going to handle
this, but I'm thinking about starting the singleton in a
MBean (or perhaps in a servlet loaded on startup in the web
application) and then binding the reference to the singleton
in JNDI from there. It's perfectly legal to reference JNDI
resources from within EJBs. The singletons that I'm dealing
with already implement an interface, so I only have to add
the interface as a support class in the EJBs and access the
singleton through it. This solution still isn't great -
there would still be multiple instances of the singleton in
a clustered deployment - but at least it gets around the
isolation that the classloading heirarchy creates.
Anyone care to confirm what I'm saying...that this guy's
problem is due to separate class loaders ? Anyone care to
critique my proposed solution - bind and lookup in JNDI ?