January 2012 - arquillian-issues - Jboss List Archives

[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, 1 month

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, 1 month

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, 1 month

6
10
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, 1 month

4
3
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-724) Upgrade to ShrinkWrap Resolver 1.1.0-alpha-2 in arquillian-parent.pom

by Juergen Zimmermann (Created) (JIRA)

Upgrade to ShrinkWrap Resolver 1.1.0-alpha-2 in arquillian-parent.pom --------------------------------------------------------------------- Key: ARQ-724 URL: https://issues.jboss.org/browse/ARQ-724 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Build Infrastructure Affects Versions: 1.0.0.CR7 Reporter: Juergen Zimmermann arquillian-parent.pom uses 1.0.0-beta-5. However, the current version is 1.1.0-alpha-2. -- 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] Created: (ARQ-473) DeployableContainer should not be restricted to only deploy Descriptors or Archives

by Aslak Knutsen (JIRA)

DeployableContainer should not be restricted to only deploy Descriptors or Archives ----------------------------------------------------------------------------------- Key: ARQ-473 URL: https://issues.jboss.org/browse/ARQ-473 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation, Deployable Containers SPI Affects Versions: 1.0.0.CR1 Reporter: Aslak Knutsen Fix For: 1.1.0.CR1 To open up for more specialized Containers we should support some type of 'WildCard' Deploy. Possible by having a Annotation driven DeployableContainer, e.g. @Deploy public SomethingExposedInContext(SomeRandomOtherType type) This will let us e.g. deploy Files/ Images etc directly for non Java/EE type Containers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (ARQ-417) Support maven deployments

by Adrian Cole (JIRA)

Support maven deployments ------------------------- Key: ARQ-417 URL: https://issues.jboss.org/browse/ARQ-417 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Configuration Reporter: Adrian Cole Microdeployments via ShrinkWrap are a nimble deployment mechanism that allows developers to test bytecode skipping the build. Another usecase is to have ARQ in a CI loop, testing artifacts post-deploy. For this sort of scenario, it would be useful to reuse test cases from the microdeployments, but have them leveraged against code pulled from maven artifacts published in a prior step. For example, we could have an @Maven annotation which could define the coordinates of an ear file, and place that on a test scenario that performs the war, ejb, cdi, etc tests of from the dependent modules. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
8
0 / 0

[JBoss JIRA] Created: (ARQ-600) Improve Tomcat codebase - Managed

by Aslak Knutsen (JIRA)

Improve Tomcat codebase - Managed --------------------------------- Key: ARQ-600 URL: https://issues.jboss.org/browse/ARQ-600 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tomcat Containers Reporter: Aslak Knutsen Assignee: Karel Piwko Fix For: tomcat_1.0.0.Final After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. We can create a similar tomcat-common-managed that will have the common parts between the different versions. {note} If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? {note} -- 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-250) Add Mobicents Sip Servlets container

by jean deruelle (JIRA)

Add Mobicents Sip Servlets container ------------------------------------ Key: ARQ-250 URL: https://jira.jboss.org/browse/ARQ-250 Project: Arquillian Issue Type: Feature Request Reporter: jean deruelle Priority: Optional Fix For: 1.0.0.Alpha4 Need to add a Mobicents container based on the currently existing Tomcat container so that the Mobicents Sip Servlets testsuite can move to arquillian. -- 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

2
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues January 2012