5 Replies Latest reply on Jan 5, 2015 4:45 AM by kpiwko

How to parameterize deployment target during runtime?

javamaniac Dec 16, 2014 6:06 AM

Hi. I've got a remote jboss eap 6.3 via which I want to perform integration tests. At the moment to run them on a specific server group I have to specify it via an annotation:

@TargetsContainer("grp-itests")

where a jboss server group is apparently discovered during runtime. However, for my specific needs a developer should be able to change the target container via maven profiles (target server). Now, I can set up

arquillian.launch

parameter or rename container in the arquillian.xml but neither works even if I specify a server group as following:

<?xml version="1.0" encoding="UTF-8"?>
<arquillian xmlns="http://jboss.org/schema/arquillian"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://jboss.org/schema/arquillian
        http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
  <container qualifier="server-group-here" default="true">
    <configuration>
      <property name="username">${jboss-eap.username}</property>
      <property name="password">${jboss-eap.password}</property>
      <property name="managementAddress">${jboss-eap.hostname}</property>
      <property name="managementPort">${jboss-eap.port}</property>
    </configuration>
  </container>
</arquillian>

at which point arquillian always prints out an error that deployment from domain controller is not possible. Now, if I hard code @TargetsContainer as in the former example, tests are executed properly.

From that and from what is written here I assume that server groups (thus target containers) are discovered during runtime and whatever I write in container qualifier in arquillian.xml will be treated as domain controller qualifier and will always overwrite any server group qualifier. I've tried to simply add 2 deployment methods with different targeted containers, but apparently it didn't work.

    @Deployment(name="grp-test1")
    @TargetsContainer("grp-test1")
    protected static Archive<?> createLocalDeployment() {
        return createEarDeployment();
    }

    @Deployment(name="grp-itest1")
    @TargetsContainer("grp-itest1")
    protected static Archive<?> createRemoteDeployment() {
        return createEarDeployment();
    }

    protected static Archive<?> createEarDeployment() {
//actual deployment here
        }

with an exception

org.jboss.arquillian.container.test.impl.client.deployment.ValidationException: DeploymentScenario contains a target (grp-test1) not matching any defined Container in the registry.
Possible causes are: None of the 11 Containers are marked as default or you have defined a @Deployment with a @TargetsContainer of value (grp-test1) that does not match any found/configured Containers (all of em listed here), see arquillian.xml container@qualifier
  at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.throwNoMatchFound(DeploymentGenerator.java:257)
  at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.throwTargetNotFoundValidationException(DeploymentGenerator.java:245)
  at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.validate(DeploymentGenerator.java:102)
  at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:84)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Thus, I'm wondering how to:

a) Specify target container, which is discovered during runtime, via some sort of parameter.

b) Assign a deployment method to a specific container right after discovering the containers as provided by Jboss EAP.

P.S.: We are using 1.1.5.Final version and from what I see in DeploymentGenerator code the feature that I'm requesting is not yet there. Am I correct? Any workarounds?

1. Re: How to parameterize deployment target during runtime?

kpiwko Dec 16, 2014 7:12 AM (in response to javamaniac)

Hi Denys,

I'm using following workaround - arquillian.xml per Maven profile and arquillian.xml property to set path to it. Container names are hardcoded still. You can have a look here:

https://github.com/aerogear/aerogear-unifiedpush-server-integration-tests/tree/master/src/test/resources

https://github.com/aerogear/aerogear-unifiedpush-server-integration-tests/blob/master/pom.xml#L342

HTH,

Karel
Actions
2. Re: Re: How to parameterize deployment target during runtime?

javamaniac Dec 16, 2014 8:53 AM (in response to kpiwko)
Hi Karel,

thanks for feedback. However, either I missed part of your code or expressed myself vaguely In your case you always have one server group:
@TargetsContainer("main-server-group")

thus u have no problems. In my case there are multiple server groups and their name is identified at runtime. So I literally need to change that annotation at runtime. Changing arquillian.xml is apparently not an option, since the container your provide in it is always a domain controller, which then provides arquillian with all the available server groups and servers (registers them as containers). If you try to configure server group within arquillian.xml it is always treated as domain controller (or I was doing something wrong).
Actions
3. Re: Re: How to parameterize deployment target during runtime?

kpiwko Dec 17, 2014 3:55 AM (in response to javamaniac)

Denys, you're right, I've misread the problem. While multiple arquillian.xml files can help in some cases, it won't in yours.

Probably the best thing to do is to ask for feature request at ARQ jira . In theory, filtering your Java tests with Templating Maven Plugin should work - http://mojo.codehaus.org/templating-maven-plugin/filter-test-sources-mojo.html - however that would most likely break IDE functionality.

You could also create your own Deployment Scenario Generator - hints here arquillian-core/AnnotationDeploymentScenarioGenerator.java at master · arquillian/arquillian-core · GitHub and make it override the default behavior. One nice example is here - @LazyDeployment forces method to be invoked prior deployment, not immediately in BeforeClass event handling - https://github.com/TadeasKriz/arquillian-osmium/tree/master/arquillian-osmium-lazy-deployment . I'd suggest to PR that to make it part of Core if you follow this way ;-)

Cheers,

Karel
Actions

4. Re: Re: Re: How to parameterize deployment target during runtime?

javamaniac Dec 22, 2014 4:48 AM (in response to kpiwko)

Karel,

we fixed it last week but I just wanted to present our solution. As you noted before, one can create a deployment scenario generator, that's exactly what we did, in fact we just adjusted the default one with something as follows:

public class ParametrizedDeploymentScenarioGenerator extends AnnotationDeploymentScenarioGenerator {
    @Override
    public List<DeploymentDescription> generate(TestClass testClass) {
        List<DeploymentDescription> deployments = super.generate(testClass);
       
        //check which container to target
        String targetContainer = System.getProperty("arquillian.target-container");
       
        if (targetContainer != null && !targetContainer.isEmpty()) {
            //multiple deployments are assumed to target same container
            for (DeploymentDescription deployment : deployments) {
                if (deployment.getTarget() == null || !deployment.getTarget().getName().equals(targetContainer)) {
                    deployment.setTarget(new TargetDescription(targetContainer));
                }
            }
        }

        return deployments;
    }
}

Thus providing proper system property now seals the deal.

1 of 1 people found this helpful

5. Re: How to parameterize deployment target during runtime?

kpiwko Jan 5, 2015 4:45 AM (in response to javamaniac)

Sweet! Do you have any plans to release this extension to Maven Central/GitHub? It would be great to add it to Modules · Arquillian page.

Thanks,

Karel
Actions

Go to original post