December 2011 - arquillian-issues

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

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

4
5
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, 9 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, 9 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, 9 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, 9 months

2
7
0 / 0

[JBoss JIRA] Created: (ARQ-480) Create a Notification SPI

by Aslak Knutsen (JIRA)

Create a Notification SPI ------------------------- Key: ARQ-480 URL: https://issues.jboss.org/browse/ARQ-480 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation, Runtime Enricher SPI Affects Versions: 1.0.0.Final Reporter: Aslak Knutsen Fix For: 1.1.0.Beta1 There should be a way for SPI impls to communicate with executor about what they have done outside of throwing exception. e.g. TestEnrcihers * EJBEnricher ran first and couldn't find a specific @EJB, but CDI runs after and can. ** EJBEnricher should not fail on his attempt, but should report what he tried and where he failed ** CDI Enricher should be executed regardless of EJBEnrichers outcome ** Summarize in the end to compare if we have a full Enriched Object -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] (ARQ-643) Arquillian fails to execute in-container tests when the serverHttps property is enabled for Glassfish containers

by Vineet Reynolds (Created) (JIRA)

Arquillian fails to execute in-container tests when the serverHttps property is enabled for Glassfish containers ---------------------------------------------------------------------------------------------------------------- Key: ARQ-643 URL: https://issues.jboss.org/browse/ARQ-643 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: GlassFish Containers Reporter: Vineet Reynolds When the {{serverHttps}} property is enabled in arquillian.xml, execution of in-container tests fail. The failure occurs at the point when the Arquillian client attempts to communicate with the Arquillian Test Runner Servlet. The {{serverHttps}} property is meant to allow for the client to communicate with the server (and the deployed test runner) over SSL, but since the test client ({{ServletUtil}}) constructs a URI with the "http" scheme and not "https", communication with the test runner fails. We'll need to * either remote this property for now, and bring this back in a future release when the test client can support communication with the Servlet test runner over SSL, * or bring in support in Arquillian Core to support communication with the Servlet test runner over SSL. -- 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

5
7
0 / 0

[JBoss JIRA] (ARQ-624) Initialization of the extension for remote Glassfish fails when the remote domain configuration does not match the expected configuration

by Vineet Reynolds (Created) (JIRA)

Initialization of the extension for remote Glassfish fails when the remote domain configuration does not match the expected configuration ----------------------------------------------------------------------------------------------------------------------------------------- Key: ARQ-624 URL: https://issues.jboss.org/browse/ARQ-624 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: GlassFish Containers Reporter: Vineet Reynolds Assignee: Vineet Reynolds Priority: Minor As explained in the title, the initialization of Arquillian fails on remote Glassfish when the domain configuration is not as expected by Arquillian. The following exception was reported when running the unit tests of glassfish-remote-3.1 against a custom configured domain: {noformat} ------------------------------------------------------------------------------- Test set: org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployWarTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 221.294 sec <<< FAILURE! org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployWarTest Time elapsed: 0 sec <<< ERROR! java.lang.NumberFormatException: null at java.lang.Integer.parseInt(Integer.java:417) at java.lang.Integer.parseInt(Integer.java:499) at org.jboss.arquillian.container.glassfish.remote_3_1.clientutils.GlassFishClientService.getAdminServerHttpPort(GlassFishClientService.java:408) at org.jboss.arquillian.container.glassfish.remote_3_1.clientutils.GlassFishClientService$AdminServer.getNodeAddressList(GlassFishClientService.java:549) at org.jboss.arquillian.container.glassfish.remote_3_1.clientutils.GlassFishClientService.startUp(GlassFishClientService.java:136) at org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployableContainer.start(GlassFishRestDeployableContainer.java:81) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$5.perform(ContainerLifecycleController.java:144) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$5.perform(ContainerLifecycleController.java:134) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:182) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:83) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:76) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:175) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainers(ContainerLifecycleController.java:75) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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.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 java.lang.reflect.Method.invoke(Method.java:597) 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.beforeSuite(EventTestRunnerAdaptor.java:68) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:76) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) at org.apache.maven.surefire.Surefire.run(Surefire.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) {noformat} The following listeners were configured in the Glassfish domain.xml file: {code:xml} ... <http-service> <access-log></access-log> <virtual-server id="server" network-listeners="http-listener,https-listener"></virtual-server> <virtual-server id="__asadmin" network-listeners="admin-listener"></virtual-server> </http-service> ... {code} The test succeeded when the name of the listeners were modified from "http-listener-1" and "http-listener-2" to "http-listener" and "https-listener" in GlassFishClientService.getAdminServerHttpPort(...). But this is not desirable, although the names of http-listener-1,http-listener-2 etc. could be useful defaults. The same might also be true of the DAS (Default Admin Server) name used by the extension (currently set to "server"). The [Domain File Format reference for the server element in domain.xml|http://download.oracle.com/docs/cd/E19226-01/820-7694/abhep/in...] states that {quote} The admin-service subelement of the config element referenced by a server's config-ref attribute determines whether the server is the DAS. {quote} which might be true of the REST API as well. Arquillian must either: 1. query Glassfish for the names of the resources before issuing requests using the REST AOU, and choose values from the responses, or 2. must allow these values to be specified in arquillian.xml. -- 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

3
3
0 / 0

[JBoss JIRA] Created: (ARQ-569) Archive for remote GF-3.1 should not be saved to disk prior to deployment

by Pedro Kowalski (JIRA)

Archive for remote GF-3.1 should not be saved to disk prior to deployment ------------------------------------------------------------------------- Key: ARQ-569 URL: https://issues.jboss.org/browse/ARQ-569 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: GlassFish Containers Affects Versions: glassfish_1.0.0.CR1 Environment: Ubuntu 11.04 x86, GlassFish Server Open Source Edition 3.1.1 (build 12) Reporter: Pedro Kowalski When I build the deployment archive, it is saved it /tmp/ARCHIVE_FILENAME (I'm running on GNU/Linux box) with chmod 444 (-r--r--r--). If I run the glassfish server as a root or as the same user as the maven than there is no problem. But actually I run a Jenkins build task (user: jenkins) and run the server as another user (user: pedro). In such case, the Arquillian remote tests fail because the Glassfish cannot use the /tmp/ARCHIVE_FILENAME (permission denied). If you change the chmod and give others the write permission - it will work fine. Aslak suggested avoiding the FileDataBodyPart during deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

7
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues December 2011