MBeans as Startup Classes, and Singletons

[bwmcadams]

I'm starting to go through the motions of migrating our application from Weblogic 6.1 to JBoss-Tomcat. One of the obvious questions that has come up is how we migrate our Startup Classes to JBoss... from everything I read, etc. an MBean is the right way to go.

Here's how it works: our startup classes are all preload methods upon "Cache" objects... they store in memory things like Security Master information from JJKenny so that when market searches, etc. are performed, we aren't hitting the database. In Weblogic, at startup we run the start methods and preload the cache from the DB. This is all done using singletons. With Weblogic, the AppServer runs the Startup class, which creates the singleton instance. Future calls to the Cache object get the same singleton instance, based upon the singleton model. (The constructor kicks off the database load).

I've tried implementing a simple MBean in JBoss 3.0.6 which has a start method that simply calls getInstance. This works fine - when JBoss starts up, it reads the SAR file, deploys my MBean, and I watch in my log as it loads the cache. Then I try calling an EJB in the JBoss container, which contains a getInstance call...and it starts loading the cache again (based on debug info it's clearly calling the constructor, meaning it can't find the instance the MBean created).

What am I doing wrong here? Could someone walk me through creating a proper MBean that will use a singleton instance of my cache object in a way that EJBs can use the same instance, thereby preloading my cache? Or is this not possible?

[adrian.brock]

The singleton should be shared if your classes
are shared.

Try logging the following

singleton.getClass().getClassLoader();

Regards,
Adrian

[jacqueso]

Another option would be to bind the object from getInstance to a JNDI name an in your ejb look it up and use it. It works for me !

[bgw2]

How did you bind a singleton in JNDI such that it could
be found in another classloader ? I tried this, but found
that the class to be bound had to be serializable, and this
defeats the purpose of using a Singleton - you'd want to
get data by executing the same instance of object, not
reading a serialized snapshot of it.