[JBoss JIRA] (ARQ-1340) Drone webdriver is not created during @BeforeClass
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/ARQ-1340?page=com.atlassian.jira.plugin.s... ]
Matous Jobanek updated ARQ-1340:
--------------------------------
Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/53
> Drone webdriver is not created during @BeforeClass
> --------------------------------------------------
>
> Key: ARQ-1340
> URL: https://issues.jboss.org/browse/ARQ-1340
> Project: Arquillian
> Issue Type: Bug
> Components: Extension - Drone
> Affects Versions: drone_1.1.1.Final
> Environment: Arquillian JUnit Container 1.0.3.Final
> Arquillian Graphene Webdriver 2.0.0.Alpha3
> Arquillian Drone dependencies and Selenium dependencies 1.1.1.Final
> Arquillian Core dependencies 1.0.3.Final
> junit 4.8.1
> jdk 1.6
> Reporter: Alex Okrushko
> Fix For: drone_2.0.0.Beta1
>
>
> Drone webdriver is not created during @BeforeClass, however *is created during @Before or if called by GrapheneContext.getProxy()*
> The following does NOT work:
> {code:java}
> @RunWith(Arquillian.class)
> public class TestDroneLogin {
> @Drone
> private static WebDriver driver;
>
> @BeforeClass
> public static void setup(){
> //GrapheneContext.getProxy().navigate().to("http://google.com");
> driver.navigate().to("http://google.com");
> }
>
> @Test
> public void testInput(){
> driver.findElement(By.cssSelector("input#gbqfq"));
> }
> }
> {code}
> However, if I use {{GrapheneContext.getProxy()}} instead of {{driver}}, everything works as expected:
> {code:java}
> @BeforeClass
> public static void setup(){
> GrapheneContext.getProxy().navigate().to("http://google.com");
> }
> {code}
> ALSO, if {{@Before}} is used then Drone webdriver is created as expected, so this problem is specific to {{@BeforeClass}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated ARQ-1992:
-----------------------------
Description:
ServletTestRunner saves ThreadLocal reference to ServletContex in its init() method,
and clears it in destroy().
Problem is that thread that calls init and thread that call destroy() are not guaranteed to be the same thread.
In wildfly/undertow undeploy/server shotdown is executed in different thread than he one that was used to call servlet init first.
reproducer and some evaluation on the bug can be found at https://github.com/wildfly/wildfly/issues/8263
was:
ServletTestRunner saves reference to ServletContex in its init() method,
and clears it in destroy().
Problem is that thread that calls init and thread that call destroy() are not guaranteed to be the same thread.
In wildfly/undertow undeploy/server shotdown is executed in different thread than he one that was used to call servlet init first.
reproducer and some evaluation on the bug can be found at https://github.com/wildfly/wildfly/issues/8263
> ServletTestRunner is leaking memmory
> ------------------------------------
>
> Key: ARQ-1992
> URL: https://issues.jboss.org/browse/ARQ-1992
> Project: Arquillian
> Issue Type: Bug
> Components: Base Implementation
> Affects Versions: 1.1.9.Final
> Environment: Using arquillian with servlet protocol
> Reporter: Tomaz Cerar
> Priority: Critical
>
> ServletTestRunner saves ThreadLocal reference to ServletContex in its init() method,
> and clears it in destroy().
> Problem is that thread that calls init and thread that call destroy() are not guaranteed to be the same thread.
> In wildfly/undertow undeploy/server shotdown is executed in different thread than he one that was used to call servlet init first.
> reproducer and some evaluation on the bug can be found at https://github.com/wildfly/wildfly/issues/8263
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory
by Tomaz Cerar (JIRA)
Tomaz Cerar created ARQ-1992:
--------------------------------
Summary: ServletTestRunner is leaking memmory
Key: ARQ-1992
URL: https://issues.jboss.org/browse/ARQ-1992
Project: Arquillian
Issue Type: Bug
Components: Base Implementation
Affects Versions: 1.1.9.Final
Environment: Using arquillian with servlet protocol
Reporter: Tomaz Cerar
Priority: Critical
ServletTestRunner saves reference to ServletContex in its init() method,
and clears it in destroy().
Problem is that thread that calls init and thread that call destroy() are not guaranteed to be the same thread.
In wildfly/undertow undeploy/server shotdown is executed in different thread than he one that was used to call servlet init first.
reproducer and some evaluation on the bug can be found at https://github.com/wildfly/wildfly/issues/8263
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive
by Alexandros Trifyllis (JIRA)
[ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.s... ]
Alexandros Trifyllis edited comment on ARQ-1986 at 10/12/15 5:51 AM:
---------------------------------------------------------------------
I did not have time to try to recreate the issue with a simple project and pom. I suppose that the issue occurs because of some configuration in my pom. I am posting it here for reference:
{code:xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>gr.dias</groupId>
<artifactId>mybank-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../mybank-parent/pom.xml</relativePath>
</parent>
<artifactId>mybank-test</artifactId>
<name>mybank-test</name>
<dependencyManagement>
<dependencies>
<!-- This bom is used to resolve versions of shrinkwrap dependencies.
It must be declared BEFORE the arquillian-bom -->
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-bom</artifactId>
<version>2.2.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.1.8.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!-- needed at compile time because the integration tests use directly
the DAOs which referece the EntityManager -->
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>gr.dias</groupId>
<artifactId>mybank-ws</artifactId>
<version>${project.version}</version>
<!-- this is how we get access to the classes of the war -->
<classifier>classes</classifier>
<scope>test</scope>
</dependency>
<!-- Arquillian integration with jUnit -->
<dependency>
<groupId>org.jboss.arquillian.junit</groupId>
<artifactId>arquillian-junit-container</artifactId>
<scope>test</scope>
</dependency>
<!--Shrinkwrap resolvers are used to resolve e.g. Maven dependencies from
pom file -->
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-depchain</artifactId>
<type>pom</type>
<scope>test</scope>
</dependency>
<!-- This is how to use a Wildfly that is already running to deploy the
war -->
<dependency>
<groupId>org.wildfly.arquillian</groupId>
<artifactId>wildfly-arquillian-container-remote</artifactId>
<version>1.0.0.CR1</version>
<scope>test</scope>
</dependency>
<!-- CXF dependencies needed for client to work -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-simple</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.ws.cxf</groupId>
<artifactId>jbossws-cxf-client</artifactId>
<scope>test</scope>
<!-- ecxlusion needed because a newer version is referenced in wildfly-arquillian-container-remote -->
<exclusions>
<exclusion>
<artifactId>jboss-logging</artifactId>
<groupId>org.jboss.logging</groupId>
</exclusion>
<exclusion>
<artifactId>asm</artifactId>
<groupId>asm</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<version>1.0.0.Alpha8</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<version>0.7.4.201502262128</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<!-- Specify maven war plugin version because previous versions do not
work well with arquillian -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
</plugin>
</plugins>
<!-- One way of including META-INF directory of generated project (wsdls,
xsds, etc). This is needed for the ws clients to work. It is not the best
way to achieve that (see http://jlorenzen.blogspot.gr/2010/07/sharing-resources-in-maven.html) -->
<testResources>
<testResource>
<directory>../mybank-generated/src/main/resources</directory>
</testResource>
<!-- we must specify the default location because it is overriden -->
<testResource>
<directory>src/test/resources</directory>
</testResource>
</testResources>
</build>
</project>
{code}
was (Author: otinanism):
I did not have time to try to recreate the issue with a simple project and pom. I suppose that the issue occurs because of some configuration in my pom. I am posting it here for reference:
{code:xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>gr.dias</groupId>
<artifactId>mybank-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../mybank-parent/pom.xml</relativePath>
</parent>
<artifactId>mybank-test</artifactId>
<name>mybank-test</name>
<dependencyManagement>
<dependencies>
<!-- This bom is used to resolve versions of shrinkwrap dependencies.
It must be declared BEFORE the arquillian-bom -->
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-bom</artifactId>
<version>2.2.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.1.8.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!-- needed at compile time because the integration tests use directly
the DAOs which referece the EntityManager -->
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>gr.dias</groupId>
<artifactId>mybank-ws</artifactId>
<version>${project.version}</version>
<!-- this is how we get access to the classes of the war -->
<classifier>classes</classifier>
<scope>test</scope>
</dependency>
<!-- Arquillian integration with jUnit -->
<dependency>
<groupId>org.jboss.arquillian.junit</groupId>
<artifactId>arquillian-junit-container</artifactId>
<scope>test</scope>
</dependency>
<!--Shrinkwrap resolvers are used to resolve e.g. Maven dependencies from
pom file -->
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-depchain</artifactId>
<type>pom</type>
<scope>test</scope>
</dependency>
<!-- This is how to use a Wildfly that is already running to deploy the
war -->
<dependency>
<groupId>org.wildfly.arquillian</groupId>
<artifactId>wildfly-arquillian-container-remote</artifactId>
<version>1.0.0.CR1</version>
<scope>test</scope>
</dependency>
<!-- CXF dependencies needed for client to work -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-simple</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.ws.cxf</groupId>
<artifactId>jbossws-cxf-client</artifactId>
<scope>test</scope>
<!-- ecxlusion needed because a newer version is referenced in wildfly-arquillian-container-remote -->
<exclusions>
<exclusion>
<artifactId>jboss-logging</artifactId>
<groupId>org.jboss.logging</groupId>
</exclusion>
<exclusion>
<artifactId>asm</artifactId>
<groupId>asm</groupId>
</exclusion>
</exclusions>
</dependency>
<!-- <dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<version>1.0.0.Alpha8</version>
<scope>test</scope>
</dependency> -->
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<version>0.7.4.201502262128</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<!-- Specify maven war plugin version because previous versions do not
work well with arquillian -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
</plugin>
</plugins>
<!-- One way of including META-INF directory of generated project (wsdls,
xsds, etc). This is needed for the ws clients to work. It is not the best
way to achieve that (see http://jlorenzen.blogspot.gr/2010/07/sharing-resources-in-maven.html) -->
<testResources>
<testResource>
<directory>../mybank-generated/src/main/resources</directory>
</testResource>
<!-- we must specify the default location because it is overriden -->
<testResource>
<directory>src/test/resources</directory>
</testResource>
</testResources>
</build>
</project>
{code}
> Jacoco extesion creates empty manifest entries removing the ones present in the archive
> ---------------------------------------------------------------------------------------
>
> Key: ARQ-1986
> URL: https://issues.jboss.org/browse/ARQ-1986
> Project: Arquillian
> Issue Type: Bug
> Components: Extension - Jacoco
> Affects Versions: jacoco_1.0.0.Alpha8
> Reporter: Alexandros Trifyllis
> Priority: Minor
>
> The ShrinkWrap generated war file contains an empty MANIFEST.MF instead of the one specified during archive creation
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive
by Alexandros Trifyllis (JIRA)
[ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.s... ]
Alexandros Trifyllis commented on ARQ-1986:
-------------------------------------------
I did not have time to try to recreate the issue with a simple project and pom. I suppose that the issue occurs because of some configuration in my pom. I am posting it here for reference:
{code:xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>gr.dias</groupId>
<artifactId>mybank-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../mybank-parent/pom.xml</relativePath>
</parent>
<artifactId>mybank-test</artifactId>
<name>mybank-test</name>
<dependencyManagement>
<dependencies>
<!-- This bom is used to resolve versions of shrinkwrap dependencies.
It must be declared BEFORE the arquillian-bom -->
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-bom</artifactId>
<version>2.2.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.1.8.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!-- needed at compile time because the integration tests use directly
the DAOs which referece the EntityManager -->
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>gr.dias</groupId>
<artifactId>mybank-ws</artifactId>
<version>${project.version}</version>
<!-- this is how we get access to the classes of the war -->
<classifier>classes</classifier>
<scope>test</scope>
</dependency>
<!-- Arquillian integration with jUnit -->
<dependency>
<groupId>org.jboss.arquillian.junit</groupId>
<artifactId>arquillian-junit-container</artifactId>
<scope>test</scope>
</dependency>
<!--Shrinkwrap resolvers are used to resolve e.g. Maven dependencies from
pom file -->
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-depchain</artifactId>
<type>pom</type>
<scope>test</scope>
</dependency>
<!-- This is how to use a Wildfly that is already running to deploy the
war -->
<dependency>
<groupId>org.wildfly.arquillian</groupId>
<artifactId>wildfly-arquillian-container-remote</artifactId>
<version>1.0.0.CR1</version>
<scope>test</scope>
</dependency>
<!-- CXF dependencies needed for client to work -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-simple</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.ws.cxf</groupId>
<artifactId>jbossws-cxf-client</artifactId>
<scope>test</scope>
<!-- ecxlusion needed because a newer version is referenced in wildfly-arquillian-container-remote -->
<exclusions>
<exclusion>
<artifactId>jboss-logging</artifactId>
<groupId>org.jboss.logging</groupId>
</exclusion>
<exclusion>
<artifactId>asm</artifactId>
<groupId>asm</groupId>
</exclusion>
</exclusions>
</dependency>
<!-- <dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<version>1.0.0.Alpha8</version>
<scope>test</scope>
</dependency> -->
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<version>0.7.4.201502262128</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<!-- Specify maven war plugin version because previous versions do not
work well with arquillian -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
</plugin>
</plugins>
<!-- One way of including META-INF directory of generated project (wsdls,
xsds, etc). This is needed for the ws clients to work. It is not the best
way to achieve that (see http://jlorenzen.blogspot.gr/2010/07/sharing-resources-in-maven.html) -->
<testResources>
<testResource>
<directory>../mybank-generated/src/main/resources</directory>
</testResource>
<!-- we must specify the default location because it is overriden -->
<testResource>
<directory>src/test/resources</directory>
</testResource>
</testResources>
</build>
</project>
{code}
> Jacoco extesion creates empty manifest entries removing the ones present in the archive
> ---------------------------------------------------------------------------------------
>
> Key: ARQ-1986
> URL: https://issues.jboss.org/browse/ARQ-1986
> Project: Arquillian
> Issue Type: Bug
> Components: Extension - Jacoco
> Affects Versions: jacoco_1.0.0.Alpha8
> Reporter: Alexandros Trifyllis
> Priority: Minor
>
> The ShrinkWrap generated war file contains an empty MANIFEST.MF instead of the one specified during archive creation
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen closed ARQ-1991.
------------------------------
> Weld EE embedded container leaks extension configuration
> --------------------------------------------------------
>
> Key: ARQ-1991
> URL: https://issues.jboss.org/browse/ARQ-1991
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Affects Versions: weld_1.0.0.CR9
> Reporter: John Ament
>
> I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module.
> The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great).
> It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration
by John Ament (JIRA)
[ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.s... ]
John Ament resolved ARQ-1991.
-----------------------------
Resolution: Cannot Reproduce Bug
After running the debuggah, it's definitely not this.
> Weld EE embedded container leaks extension configuration
> --------------------------------------------------------
>
> Key: ARQ-1991
> URL: https://issues.jboss.org/browse/ARQ-1991
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Affects Versions: weld_1.0.0.CR9
> Reporter: John Ament
>
> I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module.
> The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great).
> It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration
by John Ament (JIRA)
[ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.s... ]
John Ament commented on ARQ-1991:
---------------------------------
It's looking more like a bug in DeltaSpike. https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/...
> Weld EE embedded container leaks extension configuration
> --------------------------------------------------------
>
> Key: ARQ-1991
> URL: https://issues.jboss.org/browse/ARQ-1991
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Affects Versions: weld_1.0.0.CR9
> Reporter: John Ament
>
> I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module.
> The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great).
> It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months