ARQ-33: General Configuration Module
germanescobar Apr 12, 2010 3:48 PMI've been working on the General Configuration Module (ARQ-33) and I just want to open the discussion to the community for feedback. First, here is a class diagram of the configuration module:
The Configuration class holds the global Arquillian configuration and a Map of ContainerConfiguration implementations (the specific containers configuration). The Configuration is created by the ConfigurationBuilder and used by the different DeployableContainer implementations (i.e. JbossRemoteContainer, GlassFishEmbeddedContainer, etc.) to configure themselves. A simplified sequence diagram of the configuration would be like this (using the JBossRemoteContainer as an example):
It is a typesafe and extensible mechanism of configuring Arquillian and the different containers.
I'm also working on the XmlConfigurationBuilder that will lookup for an arquillian.xml file in the root of the classpath. For example:
<?xml version="1.0"?> <arquillian xmlns="http://jboss.com/products/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jboss="urn:java:org.jboss.arquillian.jboss" xsi:schemaLocation=" http://jboss.com/products/arquillian ...xsd urn:java:org.jboss.arquillian.jboss ...xsd"> <jboss:container> <jboss:bind address="localhost" port="8181" /> </jboss:container> </arquillian>
The jboss:container XML fragment would be mapped to the following class:
public class JBossConfiguration implements ContainerConfiguration { private String bindAddress = "localhost"; // default value private int bindPort = 8080; // default value // getters and setters not shown }
To do the mapping, XmlConfigurationBuilder uses an extension mechanism where it first loads all the ContainerConfiguration implementations (using the ServiceLoader) and then it tries to match the Namespace URI (that holds the package) with one of the ContainerConfiguration implementations. If found, it will map the child elements to the object properties and add the object to the Configuration object.
The mapping of the container tag child elements and the object can be as complex as we want it to be (i.e. support collections, arrays, etc.) but I thing we need to limit it for the alpha-2 release.
Finally, I have some questions:
- In the meeting, we talked about a <container id="..." /> tag (would be mapped to Configuration.containerId). However, this makes sense if we allow multiple containers on the classpath and we have some sort of mechanism to programatically retrieve the name of each container. What are the plans for this?
- Currently, I'm passing the Configuration object to the container through the DeployableContainer.start() method. Wouldn't it be better if we provide a DeployableContainer.setup() method to pass this information?
- A small detail. I'm naming the JBoss configuration JbossConfiguration, with a lower "b" because other classes use that standard. However, wouldn't it be better to name all those classes with a capital "B", like JBossConfiguration for example?