[JBoss JIRA] (ARQ-1237) Warp: use PortProber to determine free ports for proxy
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1237?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak commented on ARQ-1237:
-------------------------------------
Heya, no difficulties so far, besides lack of time ;) If it's fine with you I will PR by Sunday.
> Warp: use PortProber to determine free ports for proxy
> ------------------------------------------------------
>
> Key: ARQ-1237
> URL: https://issues.jboss.org/browse/ARQ-1237
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Lukáš Fryč
> Assignee: Bartosz Majsak
> Priority: Minor
> Fix For: warp_1.0.0.Beta1
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Selenium 2 uses {{PortProber}} to check free ports to run Selenium Server on.
> We can leverage that component too for Warp proxy and avoid conflicting ports.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-700) Properties in arquillian.xml should handle new lines (by trimming them)
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-700?page=com.atlassian.jira.plugin.sy... ]
Bartosz Majsak commented on ARQ-700:
------------------------------------
[~aslak] Yeah, will pull request Saturday latest.
> Properties in arquillian.xml should handle new lines (by trimming them)
> ------------------------------------------------------------------------
>
> Key: ARQ-700
> URL: https://issues.jboss.org/browse/ARQ-700
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Configuration
> Affects Versions: 1.0.0.CR6
> Reporter: Hardy Ferentschik
> Assignee: Bartosz Majsak
> Labels: starter
> Fix For: 1.0.4.Final
>
>
> When trying to add _javaVmArguments_ to _arquillian.xml_ in order to debug the container new lines in the property will cause the container start to fail.
> For example, the following works:
> {code}
> <arquillian xmlns="http://jboss.org/schema/arquillian"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://jboss.org/schema/arquillian
> http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
> <engine>
> <property name="deploymentExportPath">target/</property>
> </engine>
> <container qualifier="jboss" default="true">
> <protocol type="jmx-as7">
> <property name="executionType">REMOTE</property>
> </protocol>
> <configuration>
> <property name="jbossHome">target/jboss-as-7.1.0.Beta1</property>
> <property name="javaVmArguments">-Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m</property>
> </configuration>
> </container>
> </arquillian>
> {code}
> whereas this fails:
> {code}
> <arquillian xmlns="http://jboss.org/schema/arquillian"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://jboss.org/schema/arquillian
> http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
> <engine>
> <property name="deploymentExportPath">target/</property>
> </engine>
> <container qualifier="jboss" default="true">
> <protocol type="jmx-as7">
> <property name="executionType">REMOTE</property>
> </protocol>
> <configuration>
> <property name="jbossHome">target/jboss-as-7.1.0.Beta1</property>
> <property name="javaVmArguments">
> -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m
> </property>
> </configuration>
> </container>
> </arquillian>
> {code}
> given that often people use auto-formatting for xml the parser should take care of this and trim the configuration value. Also the resulting exception for the case where the value is on a new line is very confusing:
> {noformat}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:180)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:78)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:198)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> 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.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 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:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> 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:86)
> 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.createSuiteContext(TestContextHandler.java:60)
> 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.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> 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)
> Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [30] s
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:176)
> ... 65 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-1431) Files Left in Domain Directory at Glassfish Remote Server After Running Tests which Include Enterprise Java Beans
by Carl Hallqvist (JIRA)
[ https://issues.jboss.org/browse/ARQ-1431?page=com.atlassian.jira.plugin.s... ]
Carl Hallqvist updated ARQ-1431:
--------------------------------
Issue Type: Bug (was: Feature Request)
> Files Left in Domain Directory at Glassfish Remote Server After Running Tests which Include Enterprise Java Beans
> -----------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-1431
> URL: https://issues.jboss.org/browse/ARQ-1431
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: GlassFish Containers
> Affects Versions: 1.1.0.Final
> Environment: Java version: 1.7.0_25, vendor: Oracle Corporation
> Glassfish 4.0 / Glassfish 3.1.2
> Apache Maven 3.0.4
> Reporter: Carl Hallqvist
>
> This issue arises when tests running with Arquillian includes one or more @EJB objects as described below and running with the Glassfish remote container.
> @RunWith(Arquillian.class)
> public class GroupIntegrationTest {
> @EJB
> protected GroupService groupService;
> // ..
> }
> First time all tests pass. But the second time: "javax.ejb.EJBException: null" on all tests (even thoose tests that are not defined in a test class with an @EJB).
> I decide to delete the domain and create a new one. Testing again: all okey! next time: "javax.ejb.EJBException: null"..
> The asadmin stop-domain and start-domain does not fix it ever. Same behaivor on 3.1.2. The only thing to do is to wipeout domain using delete-domain and create-domain and then start the tests..
> The difference in the file tree after asadmin start-domain domain1 and after tests completed are shown below (where '+' sign is new files added).
> domain1
> │applications
> │ └── __internal+
> ├── generated+
> │ ├── ejb+
> │ ├── jsp+
> │ │ └── __default-web-module-server+
> │ ├── policy+
> │ │ └── __default-web-module+
> │ │ └── __default-web-module+
> │ │ └── granted.policy+
> │ └── xml+
> Hence, the domain directory is changed after running tests with Arquillian, and makes it very hard to perform regression tests since the domain must be deleted and recreated before every start of test suite.
> Qualified guessing by aslak on irc:
> [21:49] <aslak> 'maybe' some sync issue. e.g. gf return before it's completely undeployed and arq shuts it down or something
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-1431) Files Left in Domain Directory at Glassfish Remote Server After Running Tests which Include Enterprise Java Beans
by Carl Hallqvist (JIRA)
Carl Hallqvist created ARQ-1431:
-----------------------------------
Summary: Files Left in Domain Directory at Glassfish Remote Server After Running Tests which Include Enterprise Java Beans
Key: ARQ-1431
URL: https://issues.jboss.org/browse/ARQ-1431
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: GlassFish Containers
Affects Versions: 1.1.0.Final
Environment: Java version: 1.7.0_25, vendor: Oracle Corporation
Glassfish 4.0 / Glassfish 3.1.2
Apache Maven 3.0.4
Reporter: Carl Hallqvist
This issue arises when tests running with Arquillian includes one or more @EJB objects as described below and running with the Glassfish remote container.
@RunWith(Arquillian.class)
public class GroupIntegrationTest {
@EJB
protected GroupService groupService;
// ..
}
First time all tests pass. But the second time: "javax.ejb.EJBException: null" on all tests (even thoose tests that are not defined in a test class with an @EJB).
I decide to delete the domain and create a new one. Testing again: all okey! next time: "javax.ejb.EJBException: null"..
The asadmin stop-domain and start-domain does not fix it ever. Same behaivor on 3.1.2. The only thing to do is to wipeout domain using delete-domain and create-domain and then start the tests..
The difference in the file tree after asadmin start-domain domain1 and after tests completed are shown below (where '+' sign is new files added).
domain1
│applications
│ └── __internal+
├── generated+
│ ├── ejb+
│ ├── jsp+
│ │ └── __default-web-module-server+
│ ├── policy+
│ │ └── __default-web-module+
│ │ └── __default-web-module+
│ │ └── granted.policy+
│ └── xml+
Hence, the domain directory is changed after running tests with Arquillian, and makes it very hard to perform regression tests since the domain must be deleted and recreated before every start of test suite.
Qualified guessing by aslak on irc:
[21:49] <aslak> 'maybe' some sync issue. e.g. gf return before it's completely undeployed and arq shuts it down or something
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-700) Properties in arquillian.xml should handle new lines (by trimming them)
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-700?page=com.atlassian.jira.plugin.sy... ]
Aslak Knutsen commented on ARQ-700:
-----------------------------------
[~bmajsak] Did you get anywhere with the annotation?
> Properties in arquillian.xml should handle new lines (by trimming them)
> ------------------------------------------------------------------------
>
> Key: ARQ-700
> URL: https://issues.jboss.org/browse/ARQ-700
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Configuration
> Affects Versions: 1.0.0.CR6
> Reporter: Hardy Ferentschik
> Assignee: Bartosz Majsak
> Labels: starter
> Fix For: 1.0.4.Final
>
>
> When trying to add _javaVmArguments_ to _arquillian.xml_ in order to debug the container new lines in the property will cause the container start to fail.
> For example, the following works:
> {code}
> <arquillian xmlns="http://jboss.org/schema/arquillian"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://jboss.org/schema/arquillian
> http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
> <engine>
> <property name="deploymentExportPath">target/</property>
> </engine>
> <container qualifier="jboss" default="true">
> <protocol type="jmx-as7">
> <property name="executionType">REMOTE</property>
> </protocol>
> <configuration>
> <property name="jbossHome">target/jboss-as-7.1.0.Beta1</property>
> <property name="javaVmArguments">-Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m</property>
> </configuration>
> </container>
> </arquillian>
> {code}
> whereas this fails:
> {code}
> <arquillian xmlns="http://jboss.org/schema/arquillian"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://jboss.org/schema/arquillian
> http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
> <engine>
> <property name="deploymentExportPath">target/</property>
> </engine>
> <container qualifier="jboss" default="true">
> <protocol type="jmx-as7">
> <property name="executionType">REMOTE</property>
> </protocol>
> <configuration>
> <property name="jbossHome">target/jboss-as-7.1.0.Beta1</property>
> <property name="javaVmArguments">
> -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m
> </property>
> </configuration>
> </container>
> </arquillian>
> {code}
> given that often people use auto-formatting for xml the parser should take care of this and trim the configuration value. Also the resulting exception for the case where the value is on a new line is very confusing:
> {noformat}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:180)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:78)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:198)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> 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.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 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:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> 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:86)
> 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.createSuiteContext(TestContextHandler.java:60)
> 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.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> 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)
> Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [30] s
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:176)
> ... 65 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-1430) Warp does not take superclass into account when scanning for @WarpTest
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1430?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1430:
----------------------------
Original Estimate: 1 hour
Remaining Estimate: 1 hour
> Warp does not take superclass into account when scanning for @WarpTest
> -----------------------------------------------------------------------
>
> Key: ARQ-1430
> URL: https://issues.jboss.org/browse/ARQ-1430
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha3
> Reporter: Aslak Knutsen
> Priority: Minor
> Fix For: warp_1.0.0.Beta1
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> *Given*
> {code}
> @WarpTest
> @RunAsClient
> public abstract class BaseRepositoryResourceBehavior<DOMAIN extends Identifiable> {
> ...
> }
> @RunWith(Arquillian.class)
> public class ConferenceResourceBehaviorTestCase extends BaseRepositoryResourceBehavior<Conference> {
> ...
> }
> {code}
> *Then*
> {code}
> java.lang.IllegalStateException: The Warp runtime isn't initialized. You need to annotate a test class with @WarpTest in order to initialize Warp.
> at org.jboss.arquillian.warp.Warp.initiate(Warp.java:41)
> at org.cedj.geekseek.web.rest.core.test.integration.resource.BaseRepositoryResourceBehavior.shouldHandleMissingResource(BaseRepositoryResourceBehavior.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months