-
1. Re: Multiple @Deployment for different container types in one test
aslak Sep 26, 2011 4:35 AM (in response to pedrokowalski)We have two different use cases here.
1. Support multiple containers in one run, and target deployments individually
This is supported today, but has some limitations. You can use the group element in arquillian.xml to configure multiple different configurations of a single container type and target deployments in the TestClass to them individually.
<group> <container qualifier="c1" /> <container qualifier="c2" /> </group>
@RunWith(Arquillian.class) public class TestClass { @Deployment(name = "d1") @TargetsContainer("c1") public static WebArchive deployToC1() {} @Deployment(name = "d2") @TargetsContainer("c2") public static WebArchive deployToC2() {} @Test @OperatesOnDeployment("d1") public void shouldRunInContextOfD1OnC1() {} @Test @OperatesOnDeployment("d2") public void shouldRunInContextOfD2OnC2() {} }
What Arquillian will do in this scenario is to start/connect to both containers in the group within the same run, so both will be active.
The limitation is that container c1 and c2 has to be of the same type, e.g. JBoss AS 7 Managed. The most common user will most likely run a single server type, so this is not to much of a hassle.
Tho the original intent was to support mixes of different containers as well, e.g. c1 being a JBoss AS 7 container and c2 being a GlassFish 3.1 container. This is where the container/dependencies configuration came in. But we ran into to many ClassLoading issues at the time of impl, so the handling of dependencies has been removed from core. We will revisit this for 1.1+ by probably introducing something like JBoss Modules on the client side and let it handle the havy isolation / classloading issues.
2. Support different deployments based on running container
This is currently not supported directly by Arquillian today, with out relying on System Properties or other means. In this case you have the same single deployment that you want to deploy, but different contianers needs different versions of it. e.g. a CDI based deployment for Tomcat requires Weld Servlet, but not JBoss AS 6.
<container qualifier="c1" /> <container qualifier="c2" />
@RunWith(Arquillian.class) public class TestClass { @Deployment @ActiveWhenContainerIs("c1") public static WebArchive deployToC1Types() {} @Deployment @ActiveWhenContainerIs("c2") public static WebArchive deployToC2Types() {} @Test public void shouldRunInContextOfDeployment() {} }
In this scenario, depending on which container is running, c1 or c2, the different deployment would be used. You would typically run the TestSuite against one specific container and have the TestClass 'configure' it self accordingly
mvn test -Parquillian.launch=c1 mvn test -Parquillian.launch=c2
(@ActiveWhenContainerIs is a fictional annotation and just used for illustration)
-
2. Re: Multiple @Deployment for different container types in one test
pedrokowalski Sep 26, 2011 11:07 AM (in response to aslak)Thanks a lot Aslak for your time and detailed description.
Ok, so at this moment, I think the second case would be more interesting.
Is there a way to get information about which container is currently active? I guess that this container registers somehow in Arquillian-core so it should be possible?
TIA.
Cheers,
Pedro
-
3. Re: Multiple @Deployment for different container types in one test
aslak Sep 26, 2011 11:50 AM (in response to pedrokowalski)In a Extension you can @Inject Instance<ContainerRegistry>, that will tell you all registered containers.
And possible you can intercept the event DeployDeployment and not call proceed if the Deployment does not match the Container, that will basically cancel the Event for further processing.
public void someMethod(@Observes EventContext<DeploymentEvent> context) { if( 'something match' ) { context.proceed(); } }
But you have no link between @Deployment Method and Deployment which makes it hard to add MetaData for matching against without rescanning the TestClass (which might not give you a unique answer, and might not even come from the Class )
For 1.1/2.0 there is planned some form of MetaData layer between what Arq operates on and how it is read, but currently we have some direct reflections calls and 'static' metadata (DeploymentDescription) that is not too helpful to a extension in this case where you want to add more data.
For now, It's probably better to do the initial filtering in the DeploymentScenarioGenerator, before it's read into the DeploymentScenario.
-
4. Re: Multiple @Deployment for different container types in one test
pedrokowalski Sep 27, 2011 1:18 PM (in response to pedrokowalski)Aslak, should the observer of the EventContext<DeploymentEvent> (the method you posted) be fired when the method is in DeploymentScenarioGenerator registered as a LoadableExtension?
It doesn't fire in my case...
-
5. Re: Multiple @Deployment for different container types in one test
aslak Sep 27, 2011 2:51 PM (in response to pedrokowalski)There is a difference between a Service and a Observer in Arquillian, they can't be the same(or they can, but it won't be the same instance).
DeploymentScenarioGenerator is a Service that 'some' Observer expose as a extension point.
ExtensionBuilder.service(Interface, Impl) vs ExtensionBuilder.observer(Class)
All Events are Observed by Observers.
-
6. Re: Multiple @Deployment for different container types in one test
pedrokowalski Sep 27, 2011 3:01 PM (in response to aslak)Thanks a lot. I guess I will have to catch up with the Arquillian architecture :-)
Cheers!