April 2012 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-840) Should allow to define a Container configuration with only default options

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-840: --------------------------------- Summary: Should allow to define a Container configuration with only default options Key: ARQ-840 URL: https://issues.jboss.org/browse/ARQ-840 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 1.0.0.CR7 Reporter: Aslak Knutsen Fix For: 1.0.0.Final arquillian.xsd require container/configuration/property, which makes it impossible to configure a container with default options. This is only a problem when you have multiple container configurations -- 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, 9 months

1
2
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, 9 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, 9 months

4
4
0 / 0

[JBoss JIRA] (ARQ-857) Verify Arquillian Core can run on JDK 1.5

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-857: --------------------------------- Summary: Verify Arquillian Core can run on JDK 1.5 Key: ARQ-857 URL: https://issues.jboss.org/browse/ARQ-857 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Drone, Extension - Persistence, Extension - Seam2, JBoss AS Containers, Test Protocol SPIs and Implementation, Tomcat Containers Affects Versions: 1.0.0.CR7 Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.0.0.Final Setting compiler options target/source to 1.5 is not enough to verify that the code can actually run on JDK 1.5 since it ignores API changes. To avoid forcing developers to have JDK 1.5 installed to compile, we can add e.g. the Animal Sniffer Maven Plugin to verify using usage of JDK based on known api signatures. -- 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, 9 months

1
5
0 / 0

[JBoss JIRA] (ARQ-858) Should validate that a TestClass does not contain multiple same named Archives with the same Target

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-858: --------------------------------- Summary: Should validate that a TestClass does not contain multiple same named Archives with the same Target Key: ARQ-858 URL: https://issues.jboss.org/browse/ARQ-858 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR8 Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.0.0.Final The backing container implementations can in most cases not handle a automatic redeploy of a same named archive and will in some cases silently ignore the call. In most cases this is a programming error from the developer that cause confusion. If redeploy support is requested as a feature, a proper API/SPI should be put in place. {code:title=Not Allowed} @Deployment(name = "X") return ShrinkWrap.create(JavaArchive.class, "test.jar") @Deployment(name = "Y") return ShrinkWrap.create(JavaArchive.class, "test.jar") {code} This will cause "java.lang.IllegalArgumentException: Can not add multiple org.jboss.shrinkwrap.api.Archive archive deployments with the same archive name test.jar that target the same target _DEFAULT_" {code:title=Allowed} @Deployment(name = "X") @TargetsContainer("X") return ShrinkWrap.create(JavaArchive.class, "test.jar") @Deployment(name = "Y") @TargetsContainer("Y") return ShrinkWrap.create(JavaArchive.class, "test.jar") {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, 9 months

1
3
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, 9 months

6
10
0 / 0

[JBoss JIRA] (ARQ-860) Prepare 1.0.0.Final Core release

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-860: --------------------------------- Summary: Prepare 1.0.0.Final Core release Key: ARQ-860 URL: https://issues.jboss.org/browse/ARQ-860 Project: Arquillian Issue Type: Release Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR8 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, 9 months

1
1
0 / 0

[JBoss JIRA] (ARQ-735) Problem with @Before - @After methods for in-container mode

by George Vagenas (JIRA)

George Vagenas created ARQ-735: ---------------------------------- Summary: Problem with @Before - @After methods for in-container mode Key: ARQ-735 URL: https://issues.jboss.org/browse/ARQ-735 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR7 Reporter: George Vagenas Priority: Minor Working with an unmanaged deployment and container in manualy mode. I notice that when running on in-container test mode there is an problem with the @Before and @After methods. More specific for the first test in the suite, only the @Before method is being called while the @After method is never get called. For the rest of the test cases, neither the @Before nor the @After method is get called. -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] (ARQ-736) Problem with ContainerController and passing config

by George Vagenas (JIRA)

George Vagenas created ARQ-736: ---------------------------------- Summary: Problem with ContainerController and passing config Key: ARQ-736 URL: https://issues.jboss.org/browse/ARQ-736 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Base Implementation, Deployable Containers SPI Affects Versions: 1.0.0.CR7 Reporter: George Vagenas I am using ContainerController to manually start and stop the container between test executions and pass new configuration parameters if needed. The problem is that once i pass some parameters for a test, the new configuration with the extra parameters is still there for the next test, if the test doesn't define any extra parameters and should work only with the configuration provided by arquillian.xml. What i was expecting is to add extra configuration parameters for a specific test case and start the container, for the next test execution and if the test doesn't define any extra configuration parameters, it should start with the default configuration as defined in the arquillian.xml. Instead what is happenming is the following: Test1 -> define extra param1=12345 -> containerController.start(container, extraParameters1) -> Configuration = arquillian.xml + param1 - OK Test2 -> define extra param2 =54321-> containerController.start(container, extraParameters2) -> Configuration = arquillian.xml + param2 - OK Test3 -> define NO EXTRA PARAM -> containerController.start(container) -> Configuration = arquillian.xml + param2 - NOT OK If the previous test started the container with some extra parameters (param2) and the next test doesn't define any extra parameters, the configuration keeps the previous extra parameters instead of discard them. On the containerController.stop() the configuration should be updated again. -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] (ARQ-809) Arquillian Build Broken Using Default Config

by Andrew Rubinger (JIRA)

Andrew Rubinger created ARQ-809: ----------------------------------- Summary: Arquillian Build Broken Using Default Config Key: ARQ-809 URL: https://issues.jboss.org/browse/ARQ-809 Project: Arquillian Issue Type: Task Security Level: Public (Everyone can see) Components: Base Implementation Reporter: Andrew Rubinger Without the JBoss Nexus Repos enabled, the arquillian-core build is failing with: {code}[ERROR] Failed to execute goal on project arquillian-testenricher-cdi: Could not resolve dependencies for project org.jboss.arquillian.testenricher:arquillian-testenricher-cdi:jar:1.0.0.Final-SNAPSHOT: Could not find artifact org.jboss.weld:weld-core:jar:1.1.0.Final in central (http://repo.maven.apache.org/maven2) -> [Help 1]{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, 9 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues April 2012