2 Replies Latest reply on Nov 16, 2007 10:53 AM by Andrew Rubinger

    EJBTHREE-1114 - Cache passivation test and generics again

    Adrian Brock Master

      There were a number of problems in this area.

      1) The changes for the Pool/Cache registry broke the test
      2) There was no transaction manager available
      3) The use of generics in the new Pool/Cache registry was/is wrong/stupid

      1) I modified the MockDeployment so the test can actually run.
      This looks like a stupid api to me. There should be an EJB3Subsystem class
      that selfs bootstraps and is configurable and delegated to by the EJB3Deployer.
      Core EJB3 apis shouldn't be directly dependent on the deployment api, it should
      be the other way around.

      2) I hacked this to use the DummyTransactionManager provided by JBoss Cache
      I also had to add jboss clustering into the test classpath.
      This obviously needs fixing. We should be providing mock test objects
      like the DummyTransactionManager in a shared project.

      3) This is confused use of generics again.

      There is no need for this to be generic.

      public interface Ejb3CacheFactory<T extends StatefulCache>
      {
       T createCache();
      }
      
      public class NoPassivationCacheFactory implements Ejb3CacheFactory<StatefulCache>
      {
       public StatefulCache createCache()
       {
       return new NoPassivationCache();
       }
      }
      


      I could understand it if subclasses actually took advantage
      of the generic parameter (even though it is unlikely to be used).

      public class NoPassivationCacheFactory implements Ejb3CacheFactory<NoPassivationCache>
      {
       public NoPassivationCache createCache()
       {
       return new NoPassivationCache();
       }
      }
      


      It unnecessary anyway. It works without generics because of Covariant return types
      public interface Ejb3CacheFactory
      {
       StatefulCache createCache();
      }
      
      public class NoPassivationCacheFactory implements Ejb3CacheFactory
      {
       public NoPassivationCache createCache()
       {
       return new NoPassivationCache();
       }
      }
      


      The same goes for the registry. The part that should have been
      using generics wasn't defined properly. The collections.

      Meaning it was unusable without casting (removal of casting is the whole
      point of generics :-)

      Anyway, I didn't fix this properly in case the interfaces are intended
      to be extended where generics would make sense.

      Instead there are some horrible constructions that are pointless
      and pretty much unreadable. :-)

      If there is no real use for the generics, then the whole thing can be simplified to
      make this work:
      - HashMap<String, Class<? extends PoolFactory<? extends Pool>>> poolFactories = new HashMap<String, Class<? extends PoolFactory<? extends Pool>>>();
      + HashMap<String, Class<? extends PoolFactory>> poolFactories = new HashMap<String, Class<? extends PoolFactory>>();