9 Replies Latest reply on Nov 9, 2006 10:07 AM by wolfc

    Integration with different JBoss Cache releases

    brian.stansberry

      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.

        • 1. Re: Integration with different JBoss Cache releases
          brian.stansberry

          My next question is where/how to do this work. I'm my workspace copy of trunk, I've got JBC 2.0 compatible stuff written in the existing org.jboss.ebj3.cache.tree and org.jboss.ejb3.entity packages. I'm going to need to get that checked in at some point this week or early next week. But once I do that, the old 1.4.x compatible stuff is gone until we get the EJB3 project set up for different adapters.

          Is there a problem with converting EJB3 trunk to 2.0 compatibility, and then adding the 1.4.x adapters later? Or do you guys need 1.4 compatibility in trunk for some other purpose?

          • 2. Re: Integration with different JBoss Cache releases
            starksm64

            I believe we have to focus on getting jboss5 to the api levels we need, and then worry about introducing abstractions to allow dependencies to be decoupled for reuse in legacy profiles.

            • 3. Re: Integration with different JBoss Cache releases
              starksm64

               

              "bstansberry@jboss.com" wrote:

              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.


              This has to be done anyway as there need to be separate artifacts for each cache spi implementation. Its not practical to have this segemented based on java packages alone in a monolithic project.


              • 4. Re: Integration with different JBoss Cache releases
                wolfc

                We need the 1.4 stuff in branch 4.2 for as long as that hasn't switched.

                For SFSB I got the pieces of the puzzle here:
                http://wiki.jboss.org/wiki/attach?page=WolfC%2FEJB3Cache.png

                I think we should get a basic idea of where we're heading, so we don't run ourselves into the ground. We need different artifacts each with it's own dependencies which must never be circular.

                • 5. Re: Integration with different JBoss Cache releases
                  brian.stansberry

                   

                  "wolfc" wrote:
                  We need the 1.4 stuff in branch 4.2 for as long as that hasn't switched.


                  I won't do anything on Branch_4_2 until the decision to switch is made.


                  For SFSB I got the pieces of the puzzle here:
                  http://wiki.jboss.org/wiki/attach?page=WolfC%2FEJB3Cache.png

                  I think we should get a basic idea of where we're heading, so we don't run ourselves into the ground. We need different artifacts each with it's own dependencies which must never be circular.


                  Sure. I don't think this will be a problem; it's a pretty straightforward abstraction.

                  • 6. Re: Integration with different JBoss Cache releases
                    wolfc

                    That it is, but which class / interface goes into which component.

                    StatefulBeanContext & Pool are probably part of the ejb3-core.
                    StatefulTreeCache is part of ejb3-cache-adapter which is then dependant on core (and Cache).
                    But then core can't instantiate StatefulTreeCache and needs a plugin point.

                    • 7. Re: Integration with different JBoss Cache releases
                      brian.stansberry

                      OK, I see your point. My expectation was StatefulTreeCache remains part of core, as does the factory class I mentioned in my first post. The factory uses org.jboss.cache.Version to detect the JBC release that's available. That adds a dependency on JBC to core, but only on the very stable API of the Version class. The factory instantiates the adapter delegate via reflection. The adapter delegate lives in a JBC-version-specific project.

                      The dependency of core on org.jboss.cache.Version isn't so good.

                      IIRC, StatefulTreeCache itself is instantiated via reflection, so it and the factory can certainly be moved out of core. But your statement about needing a basic roadmap is certainly valid; this all needs to fit into an overall architecture of what the core is, what the adapters are, etc. My main concern to this point has been being sure it *could* be abstracted without too much pain; I think that's the case. I don't intend to actually do the abstraction until we have an overall plan.

                      • 8. Re: Integration with different JBoss Cache releases
                        wolfc

                        So StatefulTreeCache is the implementation of the plugin point, thus ejb3-14-cache & ejb3-20-cache both providing ejb3-cache.
                        ClusteredStatefulCache will be part of ejb3-core depending on ejb3-cache.
                        On top we have some kind of config or overall component.
                        I'll take a look at TreeCacheProviderHook.

                        • 9. Re: Integration with different JBoss Cache releases
                          wolfc

                           

                          "wolfc" wrote:
                          ClusteredStatefulCache will be part of ejb3-core depending on ejb3-cache.

                          No that's wrong. ejb3-14-cache and ejb3-20-cache depend on ejb3-core. ejb3 depends on ejb3-cache.