[JBoss JIRA] (ARQ-1571) Remove API 10 from default platform
by Karel Piwko (JIRA)
Karel Piwko created ARQ-1571:
--------------------------------
Summary: Remove API 10 from default platform
Key: ARQ-1571
URL: https://issues.jboss.org/browse/ARQ-1571
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Affects Versions: droidium_1.0.0.Alpha2
Reporter: Karel Piwko
Related to fix ARQ-1568, it is no longer necessary to check for API 10 presence. Default behavior could simply be to find out newest (highest) API level if no level is specified to create the AVD.
--
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, 10 months
[JBoss JIRA] (ARQ-1566) NPE in GlassFishClientService when connecting to a ssl only glassfish
by Daniel G (JIRA)
[ https://issues.jboss.org/browse/ARQ-1566?page=com.atlassian.jira.plugin.s... ]
Daniel G updated ARQ-1566:
--------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-container-glassfish/pull/23
Just fixing the basic NPE and using the https port instead of http if the http port is not open (-1).
Complete Fix needs https Support in Arquillian-core.
> NPE in GlassFishClientService when connecting to a ssl only glassfish
> ---------------------------------------------------------------------
>
> Key: ARQ-1566
> URL: https://issues.jboss.org/browse/ARQ-1566
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: GlassFish Containers
> Affects Versions: glassfish_1.0.0.CR4
> Reporter: Daniel G
>
> When connecting to a remote-glassfish that has no http port open
> {noformat:title=related domain.xml excerpt}
> <network-listeners>
> <network-listener port="${HTTP_LISTENER_PORT}" enabled="false" protocol="http-listener-1" transport="tcp" name
> ="http-listener-1" thread-pool="http-thread-pool"></network-listener>
> ...
> {noformat}
> the test-startup crashes with a NullPointerException.
> {noformat}
> java.lang.NullPointerException: null
> at java.util.regex.Matcher.getTextLength(Matcher.java:1234)
> at java.util.regex.Matcher.reset(Matcher.java:308)
> at java.util.regex.Matcher.<init>(Matcher.java:228)
> at java.util.regex.Pattern.matcher(Pattern.java:1088)
> at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService.getPortValue(GlassFishClientService.java:673)
> at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService.access$500(GlassFishClientService.java:41)
> at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService$ClusterServer.getNodeAddressList(GlassFishClientService.java:880)
> at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService.startUp(GlassFishClientService.java:133)
> at org.jboss.arquillian.container.glassfish.CommonGlassFishManager.start(CommonGlassFishManager.java:72)
> at org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployableContainer.start(GlassFishRestDeployableContainer.java:59)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> 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)
> ...
> {noformat}
> so i forked the build (https://github.com/dgeissl/arquillian-container-glassfish.git) and fixed the corresponding codelines.
> to finaly see that the basic https support is missing in Arquillian, cause now i get this exception:
> {noformat}
> java.lang.IllegalStateException: Error launching test MyTest public void MyTest.testMe()
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:103)
> at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> ...
> Caused by: java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
> at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
> at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
> at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at java.net.HttpURLConnection.getResponseCode(Unknown Source)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:183)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.executeWithRetry(ServletMethodExecutor.java:121)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:99)
> ... 75 more
> {noformat}
> So the basic NPE cause can be fixed but for the https support we need core changes right?
> Like mentioned in ARQ-643
--
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, 10 months
[JBoss JIRA] (ARQ-1570) Provide better parsing of ABI in connection with API level for Droidium
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1570?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1570:
-----------------------------------
Description:
Right now, there is not any tracking between available API levels and their respective ABI present in the system.
For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
Because of speed, default ABI will be choosen as x86 for some particular API level of users choice when he has not specified it explicitly. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
was:
Right now, there is not any tracking between available API levels and their respective ABI present in the system.
For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
Because of speed, default ABI will be choosen as x86 for some particular API level of users choice. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
> Provide better parsing of ABI in connection with API level for Droidium
> -----------------------------------------------------------------------
>
> Key: ARQ-1570
> URL: https://issues.jboss.org/browse/ARQ-1570
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha3
>
>
> Right now, there is not any tracking between available API levels and their respective ABI present in the system.
> For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
> For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
> Because of speed, default ABI will be choosen as x86 for some particular API level of users choice when he has not specified it explicitly. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
--
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, 10 months
[JBoss JIRA] (ARQ-1570) Provide better parsing of ABI in connection with API level for Droidium
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1570?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic reassigned ARQ-1570:
--------------------------------------
Assignee: Stefan Miklosovic
> Provide better parsing of ABI in connection with API level for Droidium
> -----------------------------------------------------------------------
>
> Key: ARQ-1570
> URL: https://issues.jboss.org/browse/ARQ-1570
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Right now, there is not any tracking between available API levels and their respective ABI present in the system.
> For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
> For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
> Because of speed, default ABI will be choosen as x86 for some particular API level of users choice. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
--
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, 10 months
[JBoss JIRA] (ARQ-1570) Provide better parsing of ABI in connection with API level for Droidium
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1570?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic resolved ARQ-1570.
------------------------------------
Resolution: Done
https://github.com/arquillian/arquillian-droidium/commit/c241da73d2d905a5...
> Provide better parsing of ABI in connection with API level for Droidium
> -----------------------------------------------------------------------
>
> Key: ARQ-1570
> URL: https://issues.jboss.org/browse/ARQ-1570
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha3
>
>
> Right now, there is not any tracking between available API levels and their respective ABI present in the system.
> For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
> For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
> Because of speed, default ABI will be choosen as x86 for some particular API level of users choice. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
--
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, 10 months
[JBoss JIRA] (ARQ-1570) Provide better parsing of ABI in connection with API level for Droidium
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1570?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1570:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha3
> Provide better parsing of ABI in connection with API level for Droidium
> -----------------------------------------------------------------------
>
> Key: ARQ-1570
> URL: https://issues.jboss.org/browse/ARQ-1570
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha3
>
>
> Right now, there is not any tracking between available API levels and their respective ABI present in the system.
> For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
> For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
> Because of speed, default ABI will be choosen as x86 for some particular API level of users choice. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
--
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, 10 months
[JBoss JIRA] (ARQ-1570) Provide better parsing of ABI in connection with API level for Droidium
by Stefan Miklosovic (JIRA)
Stefan Miklosovic created ARQ-1570:
--------------------------------------
Summary: Provide better parsing of ABI in connection with API level for Droidium
Key: ARQ-1570
URL: https://issues.jboss.org/browse/ARQ-1570
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Affects Versions: droidium_1.0.0.Alpha2
Reporter: Stefan Miklosovic
Right now, there is not any tracking between available API levels and their respective ABI present in the system.
For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
Because of speed, default ABI will be choosen as x86 for some particular API level of users choice. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
--
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, 10 months
[JBoss JIRA] (ARQGRA-412) Injection @Drone WebDriver into fragment doesn't respect qualifier annotation on fragment field
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-412?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-412:
------------------------------
Fix Version/s: 2.0.1.Final
> Injection @Drone WebDriver into fragment doesn't respect qualifier annotation on fragment field
> -----------------------------------------------------------------------------------------------
>
> Key: ARQGRA-412
> URL: https://issues.jboss.org/browse/ARQGRA-412
> Project: Arquillian Graphene
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Reporter: Jan Dosoudil
> Fix For: 2.0.1.Final
>
>
> It's related to ARQGRA-393, but I think it's another problem.
> {code:title=Sample testcase}
> @RunWith(Arquillian.class)
> @WarpTest
> @RunAsClient
> class Test {
> @Drone @First
> private WebDriver browser1;
> @FindBy(id="id") @First
> private Fragment fragment1;
> @Drone @Second
> private WebDriver browser2;
> @FindBy(id="id") @Second
> private Fragment fragment2;
> }
> {code}
> {code:title=Sample fragment}
> class Fragment {
> @Drone
> private WebDriver browser;
> }
> {code}
> {code:title=Exception}
> Caused by: java.lang.IllegalArgumentException: Retrieved a null from context, which is not a valid Drone browser object
> at org.jboss.arquillian.drone.impl.Validate.notNull(Validate.java:42)
> at org.jboss.arquillian.drone.impl.DroneTestEnricher.getDroneInstance(DroneTestEnricher.java:107)
> at org.jboss.arquillian.drone.impl.DroneTestEnricher.enrich(DroneTestEnricher.java:72)
> at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:70)
> at org.jboss.arquillian.graphene.enricher.PageFragmentEnricher.createPageFragment(PageFragmentEnricher.java:156)
> ... 71 more
> {code}
> If I removed @First annotations at all, It seems to run OK but in fragment annotated with @Second is injected default WebDriver.
--
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, 10 months
[JBoss JIRA] (ARQGRA-412) Injection @Drone WebDriver into fragment doesn't respect qualifier annotation on fragment field
by Jan Dosoudil (JIRA)
Jan Dosoudil created ARQGRA-412:
-----------------------------------
Summary: Injection @Drone WebDriver into fragment doesn't respect qualifier annotation on fragment field
Key: ARQGRA-412
URL: https://issues.jboss.org/browse/ARQGRA-412
Project: Arquillian Graphene
Issue Type: Bug
Affects Versions: 2.0.0.Final
Reporter: Jan Dosoudil
It's related to ARQGRA-393, but I think it's another problem.
{code:title=Sample testcase}
@RunWith(Arquillian.class)
@WarpTest
@RunAsClient
class Test {
@Drone @First
private WebDriver browser1;
@FindBy(id="id") @First
private Fragment fragment1;
@Drone @Second
private WebDriver browser2;
@FindBy(id="id") @Second
private Fragment fragment2;
}
{code}
{code:title=Sample fragment}
class Fragment {
@Drone
private WebDriver browser;
}
{code}
{code:title=Exception}
Caused by: java.lang.IllegalArgumentException: Retrieved a null from context, which is not a valid Drone browser object
at org.jboss.arquillian.drone.impl.Validate.notNull(Validate.java:42)
at org.jboss.arquillian.drone.impl.DroneTestEnricher.getDroneInstance(DroneTestEnricher.java:107)
at org.jboss.arquillian.drone.impl.DroneTestEnricher.enrich(DroneTestEnricher.java:72)
at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:70)
at org.jboss.arquillian.graphene.enricher.PageFragmentEnricher.createPageFragment(PageFragmentEnricher.java:156)
... 71 more
{code}
If I removed @First annotations at all, It seems to run OK but in fragment annotated with @Second is injected default WebDriver.
--
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, 10 months
[JBoss JIRA] (ARQ-1550) domain container - exception when connecting to existing domain without any servers
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/ARQ-1550?page=com.atlassian.jira.plugin.s... ]
Martin Simka resolved ARQ-1550.
-------------------------------
Resolution: Rejected
I'm resolving this issue as rejected, because jboss-as-arqullian-container-domain-remote 7.2.0.Final is part of jboss-as/wildfly codebase. I will create WFLY jira for this
> domain container - exception when connecting to existing domain without any servers
> -----------------------------------------------------------------------------------
>
> Key: ARQ-1550
> URL: https://issues.jboss.org/browse/ARQ-1550
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBoss AS Containers
> Affects Versions: 1.1.1.Final
> Environment: remote domain without any servers
> arquillian-bom 1.1.1.Final
> jboss-as-arquillian-container-domain-remote 7.2.0.Final
> Reporter: Martin Simka
>
> {noformat}
> (E) ManagerProcessing
> (O) LoadableExtensionLoader.load
> (E) ServiceLoader
> (E) ManagerStarted
> (O) ConfigurationRegistrar.loadConfiguration
> (E) ArquillianDescriptor
> (O) ContainerRegistryCreator.createRegistry
> (E) ContainerRegistry
> (O) ProtocolRegistryCreator.createRegistry
> (E) ProtocolRegistry
> (E) BeforeSuite
> (I) TestContextHandler.createSuiteContext
> (O) ContainerEventController.execute
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.setupContainers
> (E) SetupContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.setupContainer
> (E) BeforeSetup
> (E) Container
> (E) AfterSetup
> (O) ClientContainerControllerCreator.createClientSideContainerController
> (E) ContainerController
> (O) ClientDeployerCreator.createClientSideDeployer
> (E) Deployer
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.startSuiteContainers
> (E) StartContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.startContainer
> (E) BeforeStart
> (E) ManagementClient
> (E) ArchiveDeployer
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> java.lang.IllegalArgumentException: null
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1194)
> at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:116)
> at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:126)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
> {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, 10 months