1 Reply Latest reply on May 2, 2012 3:52 AM by aslak

    Smarter container configuration activation

    dan.j.allen

      Activing container configuration right now is a real pain and, to be honest, pretty brain dead. It requires the user to manually correlate the choice of container adapter with the choice of container configuration.

       

      We should first stand back and try to understand the instinct of a novice user, because that puts the usability into perspective.

       

      Let's assume I plan to run my tests with two container adapters, Embedded GlassFish and Managed AS 7. I include the appropriate Maven profiles in pom.xml and configuration elements in arquillian.xml.

       

      I first run the tests with the Embedded GlassFish adapter by activating the Maven profile that contains it:

       

      mvn test -Parquillian-glassfish-embedded
      

       

      I set the container configuration for Embedded GlassFish as the default, so it gets selected and all is good.

       

      Now I run the tests with Managed AS 7 by activating the other Maven profile:

       

      mvn test -Parquillian-jbossas-managed
      

       

      This time I get a warning that container configuration properties I have specified don't match the container adapter and, crap, Arquillian bailed out because it couldn't find the JBoss AS instance.

       

      What happened?

       

      While it's perfectly clear to the user that selecting a different Maven profile should select a different container configuration, Arquillian doesn't see that linkage. Instead, it tries to use the configuration for Embedded GlassFish again.

       

      Irritated, the developer looks up how to switch the container configuration. The docs tell the developer to put the qualifier of the container configuration they want to activate in a file named arquillian.launch. This qualifier is not to be confused with the name of the Maven profile, which are orthogonal things (to us, not the developer).

       

      This is just braindead. While there are advanced cases when explicit activation is probably going to be needed, in nearly all cases the developer is going to be facing a basic scenario like this one.

       

      How can this be resolved?

       

      I propose that we offer an SPI for container configuration activation. We can then provide some nice options in the way of extensions for doing container selection like in this use case.

       

      For example, an extension could match the qualifier name to the package name of the container implementation to decide which configuration to activate. It could read a mapping file that the user provides. Or it could use a remote registry. Anything is possible once this aspect of Arquillian is pluggable.

       

      Hence the feature request, ARQ-906.

        • 1. Re: Smarter container configuration activation
          aslak

          I am wondering tho what is the 90% usecase for Arquillian, I would assume it is running the same container type(possible a mix between embedded/managed/remote) with different configuration and not jboss, glassfish and tomcat.

           

          <container qualifier="dev" />
            
          <container qualifier="test">
            <configuration>
              <property name="address">5.6.7.8</property>
            </configuration>
          </container>
            
          <container qualifier="stage">
            <configuration>
              <property name="address">1.2.3.4</property>
            </configuration>
          </container>
          

           

          Taking this example, dev = Managed, test and stage = Remote.

           

          (Currently dev is not needed since it's using all default container config, just for illustration)

           

          Classpath alone is not enough to determine which qualifier to use.

           

          (i'm not saying we couldn't swap between dev and one of test/stage automatically based on container type, but how to deal with test vs stage)