[jboss-dev-forums] [Design of EJB 3.0] - Integration with different JBoss Cache releases
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:
SFSBs:
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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983509#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...