The contract between a DeployableContainer and Protocol is not clean

[starksm64]

Issue Overview

The components of a test with a shrinkwrap deployment are:

1. A unit test class that contains a static method with an @Deployment annotation that returns a shrinkwrap archive or descriptor.
2. A DeployableContainer that knows how to deploy the test artifact to some container
3. A Protocol that handles the invocation of the test method on the deployment in the container.

There are two interfaces that defined how the Protocol and DeployableContainer interact. The relevant DeployableContainer method is:

public interface Protocol<T extends ProtocolConfiguration> {
   // Allows a Protocol to augment a deployment archive with protocol specific content
   DeploymentPackager getPackager();

    // Defines how to invoke a test method
    // ProtocolMetaData comes from the DeployableContainer#deploy(Archive) method
    ContainerMethodExecutor getExecutor(T protocolConfiguration, ProtocolMetaData metaData, CommandCallback callback);
}

The only relevant method on the DeployableContainer interface is the deploy method:

public interface DeployableContainer<T extends ContainerConfiguration> {
    // Deploys the test archive that has been augmented by the Protocol#getPackager()
    ProtocolMetaData deploy(Archive<?> archive) throws DeploymentException;

}

The problem here is that this couples the DeployableContainer to a Protocol if there is a need for test deployment specific ProtocolMetaData, but this is not a clean contract. A Protocol can include any content in the test deployment and the protocol specific configuration may have nothing to do with the type of compnent being tested in the DeployableContainer. For example, a JMX protocol may include an MBean, and the test may be against a servlet or rest endpoint. While the server hosting the servlet container may need to be configured to support the JMX invocation, it is a configuration that is independent of the test deployment. Even if the protocol in use was a servlet that invokes the servlet being tested, the configuration of the protocol servlet could be completely different from that of the test container; http vs https, different vhost, port, etc.

The main issue is that while there may be a relationship between the DeployableContainer and the Protocol , the ProtocolMetaData should either be an externalized config, or be generated by some new interface that takes both the ContainerConfiguration, the ProtocolConfiguration and the Archive so that one can add new without necessarily having to update the DeployableContainer#deploy(Archive) method.

Expected Behaviour

We should be able to add Protocols without necessarily having to update the DeployableContainer#deploy(Archive) method.

Current Behaviour

Currently the only want to obtain the ProtocolMetaData passed to the getExecutor(T protocolConfiguration, ProtocolMetaData metaData, CommandCallback callback) method is to have DeployableContainer#deploy(Archive) generate it.