8 Replies Latest reply on Aug 30, 2011 3:31 AM by Galder Zamarreño

    Infinispan Container

    Andrew Rubinger Master

      At JBW Galder and I got to talking over dinner, and I pointed him at ARQ as a possibility for Infinispan.  Here's the extension of that discussion, ported from email:

       

      Btw, I remember having a chat with you about potentially writing an arquillian container for Infinispan.
      
      To give you an idea, here's a classic example of what we currently do to test Infinispan:
      https://svn.jboss.org/repos/infinispan/trunk/core/src/test/java/org/infinispan/replication/SyncReplTest.java
      
      https://svn.jboss.org/repos/infinispan/trunk/core/src/test/java/org/infinispan/test/MultipleCacheManagersTest.java is key to understanding how we set it up.
      
      And here's an example for Hot Rod:
      https://svn.jboss.org/repos/infinispan/trunk/server/hotrod/src/test/scala/org/infinispan/server/hotrod/HotRodReplicationTest.scala
      https://svn.jboss.org/repos/infinispan/trunk/server/hotrod/src/test/scala/org/infinispan/server/hotrod/HotRodMultiNodeTest.scala
      
      So, it'd be interesting to find out reasons to move to an arquillian container based approach. I could prototype it in the Hot Rod module for example if there's enough benefit to it 
      

       

       

      S,

      ALR

        • 1. Re: Infinispan Container
          Andrew Rubinger Master

          The main benefit Arquillian could provide would be to eliminate the need for @Before*/@After* stuff here:

           

          https://svn.jboss.org/repos/infinispan/trunk/core/src/test/java/org/infinispan/test/MultipleCacheManagersTest.java

           

          S,

          ALR

          • 2. Re: Infinispan Container
            Aslak Knutsen Master

            We could move all the stuff in  MultipleCacheManagersTest.javaAbstractCacheTest.java and  AbstractInfinispanTest.java into a Container and hide it from the user view. Using the Enrichers to inject the Cache etc..

             

            Benefits would be:

            • TestNG and JUnit support
            • Abstract TestNG and JUnit integration code out of Infinispan
            • Leverage Arquillian extensions like Performance Monitor
            • Should be possible to test Infinispan standalone and in JBoss AS
            • The user can test Infinispan in the same way/framework as other JBoss projects, familiarity
            • ??
            • profit!

             

             

             

            • 3. Re: Infinispan Container
              Martin Gencur Novice

              What would be the requested features for embedded mode? Anyone can comment...

               

              From the above links pointing to tests I can see that every test overrides a createCacheManagers() method which basically configures all the cache managers/caches. This should be somehow preserved, IMHO. Configuring all the cache managers via xml file (arquillian.xml) might be too expensive and inconvenient.

               

              We could of course inject cache/cache manager instances directly into a testclass but they would need to be preconfigured:

               

              1) via arquillian.xml file ?

              2) via configuring cache managers in @BeforeClass method? (simulating createCacheManagers() being invoked) ?

               

              Any comments?

              • 4. Re: Infinispan Container
                Martin Gencur Novice

                I think there are two ways to go:

                 

                 

                1) Let users inherit from MultipleCacheManagersTest.java (but rename it properly) and let them write their @Before/@BeforeMethod methods where

                   they would intialize their cluster of infinispan instances. This would mean removing all the testng related stuff from all superclasses and handle this

                   by reacting on arquillian event (@Before, @After, ...) internally.

                 

                   This would look e.g. like:

                 

                   @RunWith(Arquillian.class)

                   class TestClass extends ClusterManager {   //ClusterManager is MultipleCacheManagersTest renamed

                 

                   @Before

                   void setup() {

                        CacheContainer cm1 = ...

                        CacheContainer cm2 = ...

                        registerCacheManager(cm1, cm2);   

                   }

                 

                   @Test

                   void testMethod() {

                        cache(index).put(xx)

                        manager(index).getStatus()

                        tm(cache)...

                        ...

                   }

                   }//TestClass

                 

                   The benefits would be (besides those mentioned by Aslak):

                 

                   * users could use the framework almost the same way (not overriding createCacheManagers but writing a @Before/@BeforeMethod method  

                      initializing their cluster), there would be methods like cache(index), manager(index), tm(cache) , i.e. methods inherited from MultipleCacheManagersTest.java

                 

                   Drawbacks:

                 

                   * need to always inherit from the predefined class

                 

                 

                2) Let users inject the MultipleCacheManagersTest.java into a test (of course, rename this class)

                   and operate on caches/cache managers via this injected instance. This would look e.g. like:

                 

                   @RunWith(Arquillian.class)

                   class TestClass {

                 

                   @InfinispanResource

                   ClusterManager clusterManager;

                 

                   @Before

                   void setup() {

                        CacheContainer cm1 = ...

                        CacheContainer cm2 = ...

                        clusterManager.registerCacheManager(cm1, cm2);   

                   }

                 

                   @Test

                   void testMethod() {

                        clusterManager.cache(index).put(xx)

                        clusterManager.manager(index).getStatus()

                        clusterManager.tm(cache)...

                        ...

                   }

                   }//TestClass

                 

                   Benefits would be that we don't have to inherit another class.

                 

                   Drawbacks:

                 

                   * a bit longer syntax when using caches, managers, etc.

                 

                 

                Both of these approaches would allow to point to an xml config file for infinispan and create caches based on them inside "before" methods.

                 

                Any other ideas?

                • 5. Re: Infinispan Container
                  Martin Gencur Novice

                  Well, in order to be able to use TestNG, one has to extend an Arquillian class co the first option may not be possible:)

                  • 6. Re: Infinispan Container
                    Manik Surtani Master

                    Sorry for jumping in on this so late.  Either approach looks good to me, however, it would also mean a lot of work to patch the existing test suite.  Can you think of an easy way around this? 

                    • 7. Re: Infinispan Container
                      Martin Gencur Novice

                      Hmm, I don't see an easy way around. This functionality could be added just for end users. We don't have to refactor infinispan test suite if there's no need to do it. Regarding which approach to follow, Pete suggested no. 2 since it's more flexible and I'm for it too.

                      • 8. Re: Infinispan Container
                        Galder Zamarreño Master

                        Refactoring would be crazy to do. I think it'd be easier to build any new tests this way which at the same time gives us some time to get familiar with it and see it works for us as expected. I prefer option 2 as well.