1 Reply Latest reply on May 25, 2008 12:52 AM by alrubinger

    Decoupling from MC

    alrubinger

      See http://jira.jboss.com/jira/browse/EJBTHREE-1379 and linked Forum reference.

      I've added in EJB3 Common an "EJB3 Registrar SPI" along with an MC-based implementation; this allows us to:

      * Globally access the Object Store and invoke upon it in a convenient fashion, regardless of whether you're in a managed context or not
      * Decouple EJB3 from being MC-aware (for when we realize that MC sucks and Spring is totally the way to go[1])

      In practice, it'll be the responsibility of the runtime (ie. AS Deployers, Unit Tests, etc) to call "Ejb3RegistrarLocator.bindRegistrar" and pass in a Registrar implementation (currently I've made the MC one, a small, simple facade).

      For example, a Unit Test may do:

      // Unit Tests, as the runtime, are allowed to know about MC, but the coupling ends there
      @BeforeClass
      public static void beforeClass() throws Throwable
      {
       // Bind the Ejb3Registrar
       Ejb3RegistrarLocator.bindRegistrar(new Ejb3McRegistrar(getKernel()));
      }


      ...and then anything in the process may use MC (transparently) like:

      // Bind Example
      Ejb3RegistrarLocator.locateRegistrar().bind("beanBindName",myObject);
      
      // Lookup Example
      Object myObject2 = Ejb3RegistrarLocator.locateRegistrar().lookup("beanBindName");


      So the dependency on MC from EJB3 Proxy, for example, is now removed.

      Sources:

      http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/common/src/main/java/org/jboss/ejb3/common/registrar/

      S,
      ALR

      [1] = Read sarcastically

        • 1. Re: Decoupling from MC
          alrubinger

          By the way, I'm not really keen on the names "Ejb3RegistrarLocator", "Ejb3Registrar", etc...completely non-deterministic as to what's being registered.

          Better ideas appreciated and it'll be easily refactored.

          S,
          ALR