9 Replies Latest reply on Nov 9, 2006 10:07 AM by Carlo de Wolf

    Integration with different JBoss Cache releases

    Brian Stansberry Master

      JBoss Cache 2.0 is completely API-incompatible with the JBC 1.x series. This thread is to discuss how the JBC/EJB3 integration should deal with that fact.

      I'm going to assume that EJB3 will want to integrate with different versions of JBC:

      1) 2.0 for integration into AS 5.
      2) For AS 4.2, 2.0 or 1.4.1, whichever we decide to include with 4.2
      3) 1.4.0.SP1 for integration with 4.0.5.GA. (There should be no integration differences between 1.4.0.SP1 and 1.4.1).

      Carlo has proposed breaking EJB3 into a core and then adapters for integration with different environments. So, the problem with integrating with different JBC releases would be solved by creating different adapters.

      This should be fairly straightforward, as the JBC integration is encapsulated into just 2 classes:


      Integration is in the StatefulTreeCache class, which implements ClusteredStatefulClass. I propose changing this class so it implements ClusteredStatefulCache by delegating to a JBC-version-specific adapter. I would add a factory class that is able to load and instantiate the correct adapter by checking the version of JBC available on the classpath. The static org.jboss.cache.Version.getVersionShort() method makes such a version check trivial.

      Entity Beans:

      Integration is in the TreeCacheProviderHook class. This class is itself a factory that returns an impl of org.hibernate.cache.Cache. Here I would write implementations of o.h.c.Cache that can integrate with JBC 2.0. If JBC 2.0 was on the classpath, one of those Cache impls would be returned. Otherwise, one of the existing Cache impls that ship with hibernate would be returned. Those impls can integrate with JBC 1.x.

      Medium term (i.e. after the next couple weeks) I'll want to push the new JBC 2.0 compatible o.h.c.Cache impls into the hibernate code base. But until the AS 5 beta goes out it's logistically easier to do this in EJB3.

      Biggest hassle to all this is the compile-time incompatibility between JBC releases. So, if we have different JBC adapters in the code base, the EJB3 build is going to need to be segmented to build each one separately. No surprise there. Also, in IDEs it will be a pain to have different sets of adapters on the build path -- would need to do something like have a separate Eclipse project per adapter.