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

I’ve started playing with a ‘Proxy’ Container that can dynamically load the target container for any given JBoss AS / JBoss EAP / WildFly container adapter.

The original goal was;

  • Simplify the configuration for JBoss/WildFly containers as they have 10+ different container adapters depending on which server (AS/EAP/WildFly) and which version and type.

The result is a ‘proxy’ container that based on configuration of Target Server can dynamically load the correct adapter.

<container qualifier="name" default="true">
    <property name="target">wildfly:8.1.0.Final:remote</property>
    <property name="[normalAdapterProp]">[normalAdapterVal]</property>

The target property has the format of server:version:type.

Internally it decides based on the target which adapter coordinates and adapter version to use, e.g.;

jboss eap:6.3:remote ->
jboss eap:6.0:remote ->
jboss as:7.1.1.Final:remote ->
wildfly:8.1.0.Final:remote -> org.wildfly:wildfly-arquillian-container-remote:8.1.0.Final
wildfly:9.0.0.Alpha1:managed -> org.wildfly.arquillian:wildfly-arquillian-container–managed:9.0.0.Alpha1

(The crude logic can be found here:

A few of the interesting side effect of the dynamic artifact resolution are:

  • No more Server client dependencies on application classpath
  • Ability to configure multiple Maven Surefire Executions in the same profile and target multiple different Target servers
  • Ability to configure a group in Arquillian configuration and target multiple different ‘JBoss’ runtimes without the use of the Droidium multi container extension.

Some downside of the current impl is:

  • The normal Arquillian extension model is by-passed for the dynamically loaded adapter, meaning nothing besides the ‘DeployableContainer’ work.
  • How to configure the ShrinkWrap Resolver instance?

The source can be found here:


Another simplification that could be added would be;

  • If type=managed and no jbossHome is set, dynamically download/extract the defined server and version and set the jbossHome.

It will only work for JBoss AS and WildFly containers as EAP doesn’t have any Maven’ified dist. Tho we could add a log message like: Download EAP from X.

Do you think we could prepare some kind of adapter repository to make this approach even more global? In this case it only runs with JBoss, but maybe we could prepare a github repo with a configuration file with all supported adapters and all configuration required, something like Maven coordinators, name, type, … and then you refer them with a label like you do here for JBoss.

That’s the general idea for Arquillian 2.0.

It should ‘mostly’ work for Managed/Remote adapters with the current approach, but Embedded is a bit more tricky as it requires some fine tuned Classloader filtering…

If Droidium made it to that automatic class path resolution, it would be no-brainer.

I always find a bit difficult to start using Wildfly and Arquillian. Not myself at all because I know that to use Wildfly and Arquillian needs I have a Wildfly installed(uncompressed) on my computer, but it is difficult to explain to people wants to use Arquillian at first.

I know that you only need to use maven dependency plugin and then add dependency to wildfly adapter, but when you are explaining Arquillan + Wildfly it is always difficult to explain that although it is in embedded mode you need to install wildfly “manually”.

On the other side there is Apache TomEE. In this case if you are using embedded one, it is a true embedded (I mean true for what I think it should be an embedded), something that you add as dependency and you are in, Maven will download the jars for you.
But also in case of Apache TomEE managed adapter does something pretty interesting, it checks if Apache TomEE is installed and if not it downloads it from net and install it (by uncompressing the zip) into target/tomee. I think that this is awesome because when you explain arquillian it is pretty natural to think that you add an adapter and you are done you have the server ready to execute tests.

So because wildfly cannot run on embedded mode, I think that it would simplify a lot of things that Wildfly embedded adapter could do something like Apache TomEE managed adapter, and it is automatically download wildfly and install it on target.


Automatic download would be a nice addition to the proxy container.

Here you can see how it is done in TomEE and where

Project has now been renamed Arquillian Chameleon and 1.0.0.Alpha1 has been released:

automatic downloading can be done by Arquillian Spacelift. Downloading of resources from the internet is just a no-brainer by already implemented Download task.

All it takes is to implement right caching mechanism so your container installation survives the cleaning of target/.

This is already done by Droidium when you download Selendroid server apk to ~/.droidium and everytime you execute the test, it firstly looks into ~/.droidium if it finds the apk and only when not it downloads it hence you will download your container only once ever.

chameleon could do this for you for sure as well. your poms would then be clean from containers, you would put one chameleon extension to it and the switching between containers would be done in arq.xml, automatic downloading would take care of everything else e.g in BeforeSuite

is there already a way how to customize the server configuration?

I think here on adding/modifying the wildfly server:

  • adding modules (like the oracle jdbc driver)
  • modifiying the standalone.xml configuration (like adding security constraint)


There is no built in thing to handle these cases besides you’re free to point jbossHome to any ‘pre manipulated’ instance.