December 2011 - arquillian-issues

[JBoss JIRA] Created: (ARQ-141) Add option to export the generated Archive to inspect the final deployment

by Aslak Knutsen (JIRA)

Add option to export the generated Archive to inspect the final deployment -------------------------------------------------------------------------- Key: ARQ-141 URL: https://jira.jboss.org/browse/ARQ-141 Project: Arquillian Issue Type: Task Components: Configuration, Documentation Reporter: Aslak Knutsen It is useful for debugging to have Arquillian export the Archive it is about to deploy, specially in IN_CONTAINER mode. Create a ArchiveExporter EventHandler on class level and make the export folder configurable. If option is not set: don't export -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
10
0 / 0

[JBoss JIRA] Created: (ARQ-350) Map client events 1 to 1 with container events

by Aslak Knutsen (JIRA)

Map client events 1 to 1 with container events ---------------------------------------------- Key: ARQ-350 URL: https://issues.jboss.org/browse/ARQ-350 Project: Arquillian Issue Type: Feature Request Components: Base Implementation, Test Protocol SPIs and Implementation Reporter: Aslak Knutsen We should redo how the test execution lifecycles happen. In the current impl the flow is: Client(BeforSuite, BeforeClass, Before) -> Container(BeforSuite, BeforeClass, Before, Test, After, AfterClass, AfterSuite) -> Client(After, AfterClass, AfterSuite) We should map these 1 to 1 with the incontainer execution and keep the test instance alive between the calls. Client(BeforeClass) -> Container(BeforeClass) Client(Before) -> Container(Before) .. This way the execution is closer to how it normally would be, and extensions can interact with the Container/Environment or Client in the appropriate lifecycles more naturally. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (ARQ-506) Support more complex property types in container configuration

by Gerhard Poul (JIRA)

Support more complex property types in container configuration -------------------------------------------------------------- Key: ARQ-506 URL: https://issues.jboss.org/browse/ARQ-506 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Configuration Reporter: Gerhard Poul Priority: Optional It might sometimes be helpful to support arbitrary property lists within an arquillian configuration, such as when we want to make it possible to pass properties to the underlying container implementations, but that have no effect on the behavior of the arquillian-container-implementation itself. This is not to replace, but to augment the current configuration capability, such that we can provide something like the following in an arquillian.xml: <container qualifier="someQualifier" default="true"> <configuration> <propertyList name="somePropertyName"> <propertyEntry name="somePropertyEntryName" type="java.lang.String" value="someValue" /> <propertyEntry name="somePropertyEntryName2" type="java.lang.Integer" value="1234" /> ... </propertyList> <property name="someOtherProperty">someValue</property> </configuration> </container> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (ARQ-567) Supporting Test Suites (@ArquillianSuite)

by Mousavi Jahan Abadi S. M. (JIRA)

Supporting Test Suites (@ArquillianSuite) ----------------------------------------- Key: ARQ-567 URL: https://issues.jboss.org/browse/ARQ-567 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mousavi Jahan Abadi S. M. Currently, it is supported that JUnit test cases being run by Arquillian. This feature request is request for supporting test suites too to be run by Arquillian too. Idea is like: @RunWith(ArquillianSuite.class) @Suite.SuiteClasses( { TestCase1.class, TestCase2.class, .... } ) public class AllTests{ @Deployment public static JavaArchive createTestArchive(){ return ShrinkWrap.create(JavaArchive.class,"test.jar"); } } The advantages of above approach for users of Arquillian framework are: - Test cases don't needed to be modified to have: "@RunWith(Arquillian.class)" annotation. In other words, test cases will be pure JUnit code, and no Arquillian code (results in less coding for end users). - It is not necessary to include the static "@Deployment" methods in all test cases any more, and only Test Suite need to define the archieving/deployment related setting/definitions. The advantage of above approach for framework itself is: - From performance point-of-view, it becomes possible for Arquillian to deploy all test cases in the Test Suite into J2EE container in one action (one deploy/undeploy for one test suite, instead of mulitple deploy/undeploy for each test case). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

5
5
0 / 0

[JBoss JIRA] Created: (ARQ-271) TestEnricher should be called in @BeforeClass as well

by Thomas Diesler (JIRA)

TestEnricher should be called in @BeforeClass as well ----------------------------------------------------- Key: ARQ-271 URL: https://jira.jboss.org/browse/ARQ-271 Project: Arquillian Issue Type: Feature Request Reporter: Thomas Diesler The TestEnricher API could be extended such that static fields can be initialized. @Inject public static BundleContext context; @BeforeClass public static void beforeClass() { System.out.println("BeforeClass: " + context); } There would be two calls to TestEnricher. #1 After test class load, but before a call to @BeforeClass. #2 After instantiation of the test class, but before a call to @Before (#2 is the current behaviour) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
10
0 / 0

[JBoss JIRA] (ARQ-618) ValidationException "DeploymentScenario contains targets not matching any defined Container in the registry." could be even more clear

by Geoffrey De Smet (Created) (JIRA)

ValidationException "DeploymentScenario contains targets not matching any defined Container in the registry." could be even more clear -------------------------------------------------------------------------------------------------------------------------------------- Key: ARQ-618 URL: https://issues.jboss.org/browse/ARQ-618 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Geoffrey De Smet Priority: Minor I deployed to jetty 6 embedded and configured a container qualifier called "jetty-embedded". Instead of seeing this error message: {code} ValidationException: DeploymentScenario contains targets not matching any defined Container in the registry. _DEFAULT_. Possible causes are: No Deployable Container found on Classpath or your have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer value that does not match any found/configured Containers (see arquillian.xml container@qualifier) {code} I would like to see these error messages instead: if ContainerRegistry.getContainers() == 0 then {code} ValidationException: DeploymentScenario contains a target (_DEFAULT_) not matching any defined Container in the registry. Please include at least 1 Deployable Container in your Classpath. {code} otherwise {code} ValidationException: DeploymentScenario contains a target (_DEFAULT_) not matching any defined Container in the registry. Possible causes are: None of the 2 Deployable Containers on your Classpath match or you have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer of value (_DEFAULT_) that does not match any found/configured Containers (jboss-embedded, jetty-embedded), see arquillian.xml container@qualifier. {code} Every "()" part contains the runtime values. Here's the full original exception: {code} org.jboss.arquillian.container.test.impl.client.deployment.ValidationException: DeploymentScenario contains targets not matching any defined Container in the registry. _DEFAULT_. Possible causes are: No Deployable Container found on Classpath or your have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer value that does not match any found/configured Containers (see arquillian.xml container@qualifier) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:158) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:71) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:199) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
3
0 / 0

[JBoss JIRA] (ARQ-686) Remove parent artifact from Arquillian-BOM

by Aslak Knutsen (Created) (JIRA)

Remove parent artifact from Arquillian-BOM ------------------------------------------ Key: ARQ-686 URL: https://issues.jboss.org/browse/ARQ-686 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR6 Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
3
0 / 0

[JBoss JIRA] (ARQ-655) Upgrade Arquillian-Bom to consume the new ShrinkWrap Boms

by Aslak Knutsen (Created) (JIRA)

Upgrade Arquillian-Bom to consume the new ShrinkWrap Boms --------------------------------------------------------- Key: ARQ-655 URL: https://issues.jboss.org/browse/ARQ-655 Project: Arquillian Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR5 Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
6
0 / 0

[JBoss JIRA] (ARQ-619) If multiple DeployableContainers are in the classpath the exception message should clearly say that

by Geoffrey De Smet (Created) (JIRA)

If multiple DeployableContainers are in the classpath the exception message should clearly say that --------------------------------------------------------------------------------------------------- Key: ARQ-619 URL: https://issues.jboss.org/browse/ARQ-619 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 1.0.0.CR5 Reporter: Geoffrey De Smet I 've configured both arquillian-jetty-embedded-6.1 and jboss-as-arquillian-container-managed in my pom.xml. As a result of some weird exception based code in arquillian, I get this stacktrace which tells me it's another problem (which it is not): {code} org.jboss.arquillian.container.test.impl.client.deployment.ValidationException: DeploymentScenario contains targets not matching any defined Container in the registry. _DEFAULT_. Possible causes are: No Deployable Container found on Classpath or your have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer value that does not match any found/configured Containers (see arquillian.xml container@qualifier) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:158) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:71) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:199) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) {code} So, what happened? The method org.jboss.arquillian.core.impl.loadable.ServiceRegistryLoader#onlyOne throw an exception: {code} public <T> T onlyOne(Class<T> serviceClass) { Collection<T> all = all(serviceClass); if(all.size() == 1) { return all.iterator().next(); } if(all.size() > 1) { throw new IllegalStateException("Multiple service implementations found for " + serviceClass + ". " + toClassString(all)); // <================ GOOD } return null; } {code} and the method org.jboss.arquillian.container.impl.client.container.ContainerRegistryCreator#createRegistry swept it under the covers: {code} public void createRegistry(@Observes ArquillianDescriptor event) { ... if(activeConfiguration == null && reg.getContainers().size() == 0) { try { DeployableContainer<?> deployableContainer = serviceLoader.onlyOne(DeployableContainer.class); if(deployableContainer != null) { reg.create(new ContainerDefImpl("arquillian.xml").setContainerName("default"), serviceLoader); } } catch (Exception e) { // ignore // <====================================================== BAD } } // export registry.set(reg); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
4
0 / 0

[JBoss JIRA] (ARQ-632) org.jboss.arquillian.container.spi.client.protocol.metadata.JMXContext should close the JMXConnector when use of MBeanServerConnection is complete

by Scott Marlow (Created) (JIRA)

org.jboss.arquillian.container.spi.client.protocol.metadata.JMXContext should close the JMXConnector when use of MBeanServerConnection is complete -------------------------------------------------------------------------------------------------------------------------------------------------- Key: ARQ-632 URL: https://issues.jboss.org/browse/ARQ-632 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.CR5 Reporter: Scott Marlow Fix For: 1.0.0.Final The AS7 testsuite started experiencing "JMX server connection timeout 552" threads accumulating during the AS7 testsuite run. If the testsuite runs fast enough, this seems to cause "OutOfMemoryError: unable to create new native thread" errors near the end of the testsuite run. This doesn't recreate for everyone but it does for me. To accomplish this, I think we need to keep the JMXConnector returned from calling JMXConnectorFactory.connect() until we are done with the MBeanServerConnection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

6
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues December 2011