1 Reply Latest reply on Mar 4, 2003 6:59 PM by Bruce Wilson

    Weblogic -> JBoss and Startup Classes

    Brendan W. McAdams Newbie

      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?

      What is the BEST way to implement startup classes (not just of the cache type) in JBoss?

        • 1. Re: Weblogic -> JBoss and Startup Classes
          Bruce Wilson Newbie

          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
          was loaded.

          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 ?