]
Aslak Knutsen commented on ARQ-1255:
------------------------------------
The problem here is a bit two fold. First of, the Weld SE container doesn't really
support multiple deployments at this time. It will override it self on the second
deployment.
In a full blown container with support for multiple deployment doing the same is possible,
but you run into the second issue. The current multi deployment is kinda limiting in the
sense that All classes referenced in the test class much be available in both deployments.
Clearly this works better for cluster type testing then two separate apps. CDI tend to
freak out trying to scan the TestClass not and not finding the 'other inject'.
Either deploy time or runtime.
One possible fix if is to move the injections down to method level, where CDI won't
scan, only Arquillian
@Test public void should(Bean x);
The planned fix for this is to filter the TestClass during package/dpeloy time, so only
the Fields/Methods that are targeted/used in a given Deployment end up in the Deployment.
Basically rewriting the TestClass.
Multiple deployments is not working in Weld SE container
--------------------------------------------------------
Key: ARQ-1255
URL:
https://issues.jboss.org/browse/ARQ-1255
Project: Arquillian
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Weld Containers
Affects Versions: 1.0.0.CR5
Reporter: Antonin Stefanutti
Attachments: Bean1.java, Bean2.java, MultipleDeploymentArquilianCdiTest.java,
OperateOnDeploymentArquilianCdiTest.java, pom.xml, test_case_1_stacktrace.txt,
test_case_2_stacktrace.txt
As described in [Multiple
Deployments|https://docs.jboss.org/author/display/ARQ/Multiple+Deployments], multiple
{{@Deployment}} annotated methods can be declared in a test class. In addition, the
{{@OperateOnDeployment}} annotation enables the selection of a particular _deployment_ per
test method.
However, when using Arquillian with a Weld SE container, the CDI container isn't
deployed with the expected archives which ends up having {{DeploymentException}} thrown,
as illustrated in the test cases below:
*Test case 1:*
{code}
@RunWith(Arquillian.class)
public class MultipleDeploymentArquilianCdiTest {
@Inject
private Bean1 bean1;
@Inject
private Bean2 bean2;
@Deployment(name = "bean1-jar")
public static Archive<?> createBean1Jar() {
return
ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE,
"beans.xml");
}
@Deployment(name = "bean2-jar")
public static Archive<?> createBean2Jar() {
return
ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE,
"beans.xml");
}
@Test
public void multiDeploymentTest() {
assertNotNull(bean1);
assertNotNull(bean2);
}
}
{code}
*Test case 2:*
{code}
@RunWith(Arquillian.class)
public class OperateOnDeploymentArquilianCdiTest {
@Inject
private Bean1 bean1;
@Inject
private Bean2 bean2;
@Deployment(name = "beans-jar")
public static Archive<?> createBeansJar() {
return
ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE,
"beans.xml");
}
@Deployment(name = "bean1-jar")
public static Archive<?> createBean1Jar() {
return
ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE,
"beans.xml");
}
@Deployment(name = "bean2-jar")
public static Archive<?> createBean2Jar() {
return
ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE,
"beans.xml");
}
@Test
@OperateOnDeployment("beans-jar")
public void singleDeploymentTest() {
assertNotNull(bean1);
assertNotNull(bean2);
}
}
{code}
In both cases, the following exception is thrown:
{code}
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for
type [Bean2] with qualifiers [@Default] at injection point [[field] @Inject private
arquillian.test.OperateOnDeploymentArquilianCdiTest.bean2]
{code}
Note that test case 2 is working when only {{@Deployment(name = "beans-jar")}}
is declared.
Test classes and the {{pom.xml}} are attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: