February 2012 - arquillian-issues

[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

[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, 2 months

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

2
1
0 / 0

[JBoss JIRA] (ARQ-688) Arquillian can't start EAP 5.1

by Tomáš Schlosser (Created) (JIRA)

Arquillian can't start EAP 5.1 ------------------------------ Key: ARQ-688 URL: https://issues.jboss.org/browse/ARQ-688 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Environment: Arquillian 1.0.0.CR6 JBoss EAP 5.1.1 Reporter: Tomáš Schlosser When using JBoss container in manual mode and try to start it, the command throw exception because JBoss EAP does not start within 30 seconds. No command response within timeout of 30000 ms. org.jboss.arquillian.protocol.servlet.runner.ServletCommandService.execute(ServletCommandService.java:60) at org.jboss.arquillian.container.test.impl.client.container.ContainerContainerController.start(ContainerContainerController.java:45) at org.jboss.qa.brms.bre.container.TransactionsTest.foo(TransactionsTest.java:16) 98 lines not shown -- 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
3
0 / 0

[JBoss JIRA] (ARQ-792) Honor system property for debugging Arquillian internals

by Karel Piwko (JIRA)

Karel Piwko created ARQ-792: ------------------------------- Summary: Honor system property for debugging Arquillian internals Key: ARQ-792 URL: https://issues.jboss.org/browse/ARQ-792 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR7 Reporter: Karel Piwko Often an extension developer wants to know what's going in Arquillian. There is a way how to enable a debug mode, however it requires a complete build of Arquillian from source: It should honor a property instead: {code} mvn test -Darquillian.debug=true {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

2
4
0 / 0

[JBoss JIRA] (ARQ-715) Add a getter for ProtocolMetaData.contexts

by Alexis Hassler (Created) (JIRA)

Add a getter for ProtocolMetaData.contexts ------------------------------------------ Key: ARQ-715 URL: https://issues.jboss.org/browse/ARQ-715 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Base Implementation Reporter: Alexis Hassler Having a ProtocolMetaData.getContexts() method would help to safely clone (and rewrite) metadata in extensions. Without that method, we could forget some contexts. -- 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
5
0 / 0

[JBoss JIRA] (ARQ-748) Update Arquillian test dependencies to be able to do a clean build against Maven Central

by Karel Piwko (JIRA)

Karel Piwko created ARQ-748: ------------------------------- Summary: Update Arquillian test dependencies to be able to do a clean build against Maven Central Key: ARQ-748 URL: https://issues.jboss.org/browse/ARQ-748 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Build Infrastructure Affects Versions: 1.0.0.CR7 Reporter: Karel Piwko Assignee: Karel Piwko * CDI TestEnricher Current version 1.1.0.Final is not available in Maven Central. Note that the change would require an update to related slf4j bindings to 1.6.1. * Servlet Protocol jboss.web:servlet-api:jar:3.0.0.alpha-25 in not available in Maven Central to be replaced with {code:xml} <dependency> <groupId>org.jboss.spec.javax.servlet</groupId> <artifactId>jboss-servlet-api_3.0_spec</artifactId> <version>1.0.0.Final</version> </dependency> {code} * Arquillian Example Domain/JUnit/TestNG same as protocol and org.jboss.ejb3:jboss-ejb3-api:jar:3.1.0 replaced with {code:xml} <dependency> <groupId>org.jboss.spec.javax.ejb</groupId> <artifactId>jboss-ejb-api_3.1_spec</artifactId> <version>1.0.1.Final</version> </dependency> {code} and javax.jms:jms with {code:xml} <dependency> <groupId>org.jboss.spec.javax.jms</groupId> <artifactId>jboss-jms-api_1.1_spec</artifactId> <version>1.0.0.Final</version> </dependency> {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

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues February 2012