Arquillian Chameleon File Deployment

Proxy Container for all JBoss AS / JBoss EAP / WildFly containers

Have you ever faced an issue that switching between container implementations isn’t that easy?

Testing against several containers (JBoss AS / JBoss EAP / WildFly) or even switching between different modes (Managed, Remote, Embedded) may result in bloated pom.xml.

Chameleon Containers are able to quickly adopt to your needs without too much hassle.

Story

Get Started

<dependency>
    <groupId>org.arquillian.container</groupId>
    <artifactId>arquillian-chameleon-junit-container-starter</artifactId>
    <version>1.0.0.Final-SNAPSHOT</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>org.arquillian.container</groupId>
    <artifactId>arquillian-chameleon-testng-container-starter</artifactId>
    <version>1.0.0.Final-SNAPSHOT</version>
    <scope>test</scope>
</dependency>

<container qualifier="chameleon" default="true">
    <configuration>
        <property name="chameleonTarget">wildfly:8.0.0.Final:managed</property>
        <property name="serverConfig">standalone-full.xml</property>
    </configuration>
</container>

Supported Containers

Configuration options

If you want to add your own container configurations or contribute to the ones shipped as default with Chameleon you can use the following format to describe them:

1. required The name section of the chameleonTarget.

2. required A Regular Expression to match against the version section of the chamleonTarget to activate this configuration.

3. required A list of Adapters supported by this name and version combination.

4. required The Adapter that match the type section of the chameleonTarget.

5. required The Adapter artifacts GAV so it can be downloaded from a repository.

6. required The Adapter DeployableContainer implementation class to invoke.

7. The Adapter that match the type section of the chameleonTarget.

8. optional List of Adapter configuration option that will be automatically activated if not present from user.

9. ${dist} special variable that is replaced with the location of the downloaded/extracted distribution if applicable.

10. The Adapter that match the type section of the chameleonTarget.

11. ${version} special variable that is replaced with the version section of the chameleonTarget as provided by the user.

12. optional Flag to turn off default automatic download of distribution if not required by the Adapter. e.g. GlassFish Embedded requires no extracted distribution to run.

13. optional List of additional dependencies required by the Adapter.

14. The dependency GAV.

15. optional Describes which adapter to select if no type section is defined in the chameleonTarget.

16. optional Section to describe how to download the distribution.

17. The distribution artifact GAV so it can be downloaded from a repository.

18. optional Override the Adapters defaultProtocol as described by the DeployableContainer implementation.

19. optional List of dependencies to exclude when resolving the adapter GAV.

20. The dependency GAV expression to exclude.

WildFly Embedded

<dependency>
    <groupId>org.jboss.logmanager</groupId>
    <artifactId>jboss-logmanager</artifactId>
    <version>${jboss.logmanager.version}</version>
</dependency>

<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <systemPropertyVariables>
            <java.util.logging.manager>
                org.jboss.logmanager.LogManager
            </java.util.logging.manager>
        </systemPropertyVariables>
    </configuration>
</plugin>

In case you need to specify your custom settings.xml file and you cannot put it at the default location ($HOME/.m2/settings.xml) then use the property org.apache.maven.user-settings to specify a user settings.xml file or org.apache.maven.global-settings to specify a global settings.xml file.

The standard Maven property -s doesn’t work as Chameleon internally uses Shrinkwrap Resolver and the property is not supported there. But you can use any of the properties described here: https://github.com/shrinkwrap/resolver#system-properties

Arquillian Chameleon Container is a special container that allows you to define which container and mode without having to remember any concrete dependency of the desired container. You’ve seen this at Get Started.

This approach is the most versatile one and has been here for a long time and offers a generic and global solution, but with Chameleon, you can use another approach where instead of configuring container using arquillian.xml, you can use an annotation to set up the test container.

The first thing to do is add next dependency:

Then instead of using Arquillian runner, you need to use a new one provided by Chameleon called ArquillianChameleon.

Then you need to annotate your test with @ChameleonTarget("wildfly:9.0.0.Final:managed") where you set the container, version, and mode as you usually do with `chameleonTarget in arquillian.xml.

But this annotation also allows you to set each of the property (even custom properties) one by one, for example:

Last important thing to take into consideration is that @ChameleonTarget can be used in meta-annotations and inherit properties form meta-annotations. For example, you can use next form to define Tomcat container:

1. Defines container, version and mode

And then to define that the test needs to be run in Tomcat, you can simply do:

But you can even redefine meta-annotations, for example, to specify Tomcat 8 you only need to do:

1. Inherit properties from Tomcat meta-annotation

2. Override version number

All fields accept expressions like `${property:defaultValue} where property is first resolved as environment variable, if not set as the system property and if not the default value is used.

To run the whole test suite with the correct configuration use profile all:

mvn clean verify -Pall

To run Arquillian Container TCK test suite use profile tck:

mvn clean verify -Ptck

• Chat: #arquillian channel @ irc.freenode.net

• Blogs

• Forums