3 Replies Latest reply on Feb 22, 2013 3:17 PM by Guillaume Grossetie

    ARQ-638 - Best way to keep the container clean

    Guillaume Grossetie Newbie



      I'm working on the ARQ-638 feature and I sent a pull request some days ago. The basic idea was to remove the following directories before running tests :

      • standalone/data
      • standalone/tmp
      • standalone/log


      Brian Stansberry suggests that the feature should be added to container-embedded and container-managed-domain as well. Doing so I find out that the embedded container already have a similar feature :

       * [...]
       * If a clean run is wanted, you can specify <code>${jboss.embedded.root}</code> to an existing directory
       * which will copy the contents of the data and configuration directories under a temporary folder. This
       * has the effect of this run not polluting later runs of the embedded server.


      The following approach solves the problem of getting rid of unwanted data/, tmp/, log/ but also avoids problem where one test modifies the server config (e.g. standalone.xml) leaving the next test with an unsuitable config.


      The embedded container create a temporary folder inside the ${jboss.embedded.root} but AFAIK this folder is not removed after running tests. I think that the ${jboss.embedded.root} should be clean before running test. Apart for that I think the temporary folder approach is better and that the container-managed-domain and container-managed should be implemented the same way.


      The config property should then go into a superclass of ManagedContainerConfiguration and be rename something like ${jboss.temp.root}.



      What do you think ?



        • 1. Re: ARQ-638 - Best way to keep the container clean
          Karel Piwko Master

          Hello Guillaume,


          I think there is no way how to clean up a server directory better than copying the container from a vanilla directory/zip to a defined location. (That's something what can be achieved using maven-resources-plugin quite easily even now).

          That said, I think that ARQ-638 is rather a general issue for Container API about having a possibility to clean directory from last run either by specifying configuration element or programatically via API then about consolidating AS7 container adaptor features.


          I can imagine approach similar to following:



          <container qualifier="jboss">


          in arquillian.xml would trigger createCleanContainer() method of Arquillian Container API that would copy specified files from directory of (managed|embedded) container into a temporary directory created by Arquillian itself and run tests against that location.


          Or maybe better, allowing <testClassIsolation> to work as an enumeration of {suite|class|method} (similar to ARQ-336 implementation). Having this method in API would even allow user to get Container Controller via @ArquillianResource and clean container anytime he wants.



          1 of 1 people found this helpful
          • 2. Re: ARQ-638 - Best way to keep the container clean
            Guillaume Grossetie Newbie

            Hello Karel,


            Thanks for the reply

            I agree with you but I don't see how we can clean the container at runtime with the createCleanContainer() method. Maybe we could split the task to allow the user to create a clean container before its start and then provide a method in API to clean the container at "runtime" before {suite|class|method}.

            I think we need to be careful about what we can clean at "runtime" especially with the data/content directory. Do you know what can be removed/cleaned at "runtime" whitout making the deployment instable ?




            • 3. Re: ARQ-638 - Best way to keep the container clean
              Guillaume Grossetie Newbie

              Hi Karel,


              I'm starting to look at your solution and I found that the ContainerController API is quite low level. If I add a new clean() method I will have to implement the feature on each container adapters available (and that's quite a lot !) or just throw a NotYetImplementedException...

              Is that ok or did I miss something ?