From issues at jboss.org Thu Oct 1 05:27:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 1 Oct 2015 05:27:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-477) Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114074#comment-13114074 ] Matous Jobanek commented on ARQGRA-477: --------------------------------------- There is new version of the arquillian-core 1.1.9.Final sent PR: https://github.com/arquillian/arquillian-graphene/pull/139 > Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 > ----------------------------------------------------------- > > Key: ARQGRA-477 > URL: https://issues.jboss.org/browse/ARQGRA-477 > Project: Arquillian Graphene > Issue Type: Component Upgrade > Reporter: Luk?? Fry? > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 05:37:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 1 Oct 2015 05:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when a test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1979: ------------------------------- Fix Version/s: recorder_1.1.0.Alpha3 > Screenshot is not taken when a test fails > ----------------------------------------- > > Key: ARQ-1979 > URL: https://issues.jboss.org/browse/ARQ-1979 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: recorder_1.1.0.Alpha3 > > > The cause: > There in the Arquillian-core 1.1.7.Final have been changed the workflow of events and the moment when the status of a test is set > For more information see: > https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > ARQ-1818 > This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: > https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 05:37:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 1 Oct 2015 05:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1979) Screenshot is not taken when a test fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1979. ------------------------------ Resolution: Done > Screenshot is not taken when a test fails > ----------------------------------------- > > Key: ARQ-1979 > URL: https://issues.jboss.org/browse/ARQ-1979 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: recorder_1.1.0.Alpha3 > > > The cause: > There in the Arquillian-core 1.1.7.Final have been changed the workflow of events and the moment when the status of a test is set > For more information see: > https://github.com/arquillian/arquillian-core/commit/606b4b29a3a561bc0ea6ed2f4883f7e37fa5153c > ARQ-1818 > This change is not reflected there in the arquillian-recorder project - this causes that the screenshot is not taken when test fails: > https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L96 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 07:06:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 1 Oct 2015 07:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: Matous Jobanek created ARQGRA-480: ------------------------------------- Summary: Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well Key: ARQGRA-480 URL: https://issues.jboss.org/browse/ARQGRA-480 Project: Arquillian Graphene Issue Type: Bug Components: screenshooter Affects Versions: 2.1.0.Alpha2 Reporter: Matous Jobanek Consider this scenario: Arquillian.xml contains: {code:xml} true false false false {code} Then, when the test starts this output is written there in the console log: {noformat} Configuration of Arquillian Browser Screenshooter: rootDir target/screenshots screenshotType PNG takeBeforeTest true takeAfterTest false takeWhenTestFailed false takeOnEveryAction true {noformat} There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 08:03:01 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 1 Oct 2015 08:03:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQGRA-480: ---------------------------------- Fix Version/s: 2.1-Tracking > Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-480 > URL: https://issues.jboss.org/browse/ARQGRA-480 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > Consider this scenario: > Arquillian.xml contains: > {code:xml} > > true > false > false > false > > {code} > Then, when the test starts this output is written there in the console log: > {noformat} > Configuration of Arquillian Browser Screenshooter: > rootDir target/screenshots > screenshotType PNG > takeBeforeTest true > takeAfterTest false > takeWhenTestFailed false > takeOnEveryAction true > {noformat} > There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. > The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: > 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase > 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 08:25:00 2015 From: issues at jboss.org (Robert Hoeppner (JIRA)) Date: Thu, 1 Oct 2015 08:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: Robert Hoeppner created ARQGRA-481: -------------------------------------- Summary: generic attribute injection doesn't work Key: ARQGRA-481 URL: https://issues.jboss.org/browse/ARQGRA-481 Project: Arquillian Graphene Issue Type: Bug Components: core Affects Versions: 2.0.3.Final Environment: OS: Win7 Java: 1.7.0_17 AS: Wildfly 8.2.0.final Reporter: Robert Hoeppner I have an abstract PageObject like these: {code:java} public abstract class AbstractBenutzerdatenPageWithEdit extends AbstractBenutzerdatenPage { @FindBy(id = "browser:editDialog:dlg_container") private EDITDLG editDialog; public EDITDLG getEditDialog() { return editDialog; } } {code} AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: {code:java} @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") public class FristenPage extends AbstractBenutzerdatenPageWithEdit { .... public FristenDetailFragment getDetail() { return detail; } ..... } {code} at which FristenDetailFragment is one concrete implementation of AbstractEditDialogFragment The test looking like these {code:java} @RunWith(Arquillian.class) @RunAsClient public class FristenTest extends TestDeployments { @ArquillianResource private URL contextPath; @Drone private WebDriver driver; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private BenutzerdatenHomePage benutzerdatenHomePage; @Page private FristenPage fristenPage; @Test public void PageAccessTest(@InitialPage LoginPage loginP) { loginP.loginWithCredentials("admin", "gip123"); homePage.getNavigationBar().navigateToUserData(); benutzerdatenHomePage.getMenu().openFristen(); assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); } {code} And if i run this test, i get an InstanziationException -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 08:28:00 2015 From: issues at jboss.org (Robert Hoeppner (JIRA)) Date: Thu, 1 Oct 2015 08:28:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Hoeppner updated ARQGRA-481: ----------------------------------- Attachment: stacktrace.txt full stacktrace > generic attribute injection doesn't work > ---------------------------------------- > > Key: ARQGRA-481 > URL: https://issues.jboss.org/browse/ARQGRA-481 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final > Environment: OS: Win7 > Java: 1.7.0_17 > AS: Wildfly 8.2.0.final > Reporter: Robert Hoeppner > Attachments: stacktrace.txt > > > I have an abstract PageObject like these: > {code:java} > public abstract class AbstractBenutzerdatenPageWithEdit extends > AbstractBenutzerdatenPage { > @FindBy(id = "browser:editDialog:dlg_container") > private EDITDLG editDialog; > public EDITDLG getEditDialog() { > return editDialog; > } > } > {code} > AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: > {code:java} > @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") > public class FristenPage extends AbstractBenutzerdatenPageWithEdit { > .... > public FristenDetailFragment getDetail() { > return detail; > } > ..... > } > {code} > at which FristenDetailFragment is one concrete implementation of AbstractEditDialogFragment > The test looking like these > {code:java} > @RunWith(Arquillian.class) > @RunAsClient > public class FristenTest extends TestDeployments { > @ArquillianResource > private URL contextPath; > @Drone > private WebDriver driver; > @Page > private LoginPage loginPage; > @Page > private HomePage homePage; > @Page > private BenutzerdatenHomePage benutzerdatenHomePage; > @Page > private FristenPage fristenPage; > @Test > public void PageAccessTest(@InitialPage LoginPage loginP) { > loginP.loginWithCredentials("admin", "gip123"); > homePage.getNavigationBar().navigateToUserData(); > benutzerdatenHomePage.getMenu().openFristen(); > assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); > } > {code} > And if i run this test, i get an InstanziationException -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 08:29:00 2015 From: issues at jboss.org (Robert Hoeppner (JIRA)) Date: Thu, 1 Oct 2015 08:29:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Hoeppner updated ARQGRA-481: ----------------------------------- Description: I have an abstract PageObject like these: {code:java} public abstract class AbstractBenutzerdatenPageWithEdit extends AbstractBenutzerdatenPage { @FindBy(id = "browser:editDialog:dlg_container") private EDITDLG editDialog; public EDITDLG getEditDialog() { return editDialog; } } {code} AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: {code:java} @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") public class FristenPage extends AbstractBenutzerdatenPageWithEdit { .... public FristenDetailFragment getDetail() { return detail; } ..... } {code} at which FristenDetailFragment is one concrete implementation of AbstractEditDialogFragment The test looking like these {code:java} @RunWith(Arquillian.class) @RunAsClient public class FristenTest extends TestDeployments { @ArquillianResource private URL contextPath; @Drone private WebDriver driver; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private BenutzerdatenHomePage benutzerdatenHomePage; @Page private FristenPage fristenPage; @Test public void PageAccessTest(@InitialPage LoginPage loginP) { loginP.loginWithCredentials("admin", "gip123"); homePage.getNavigationBar().navigateToUserData(); benutzerdatenHomePage.getMenu().openFristen(); assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); } {code} And if i run this test, i get a PageObjectInitializationException was: I have an abstract PageObject like these: {code:java} public abstract class AbstractBenutzerdatenPageWithEdit extends AbstractBenutzerdatenPage { @FindBy(id = "browser:editDialog:dlg_container") private EDITDLG editDialog; public EDITDLG getEditDialog() { return editDialog; } } {code} AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: {code:java} @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") public class FristenPage extends AbstractBenutzerdatenPageWithEdit { .... public FristenDetailFragment getDetail() { return detail; } ..... } {code} at which FristenDetailFragment is one concrete implementation of AbstractEditDialogFragment The test looking like these {code:java} @RunWith(Arquillian.class) @RunAsClient public class FristenTest extends TestDeployments { @ArquillianResource private URL contextPath; @Drone private WebDriver driver; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private BenutzerdatenHomePage benutzerdatenHomePage; @Page private FristenPage fristenPage; @Test public void PageAccessTest(@InitialPage LoginPage loginP) { loginP.loginWithCredentials("admin", "gip123"); homePage.getNavigationBar().navigateToUserData(); benutzerdatenHomePage.getMenu().openFristen(); assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); } {code} And if i run this test, i get an InstanziationException > generic attribute injection doesn't work > ---------------------------------------- > > Key: ARQGRA-481 > URL: https://issues.jboss.org/browse/ARQGRA-481 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final > Environment: OS: Win7 > Java: 1.7.0_17 > AS: Wildfly 8.2.0.final > Reporter: Robert Hoeppner > Attachments: stacktrace.txt > > > I have an abstract PageObject like these: > {code:java} > public abstract class AbstractBenutzerdatenPageWithEdit extends > AbstractBenutzerdatenPage { > @FindBy(id = "browser:editDialog:dlg_container") > private EDITDLG editDialog; > public EDITDLG getEditDialog() { > return editDialog; > } > } > {code} > AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: > {code:java} > @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") > public class FristenPage extends AbstractBenutzerdatenPageWithEdit { > .... > public FristenDetailFragment getDetail() { > return detail; > } > ..... > } > {code} > at which FristenDetailFragment is one concrete implementation of AbstractEditDialogFragment > The test looking like these > {code:java} > @RunWith(Arquillian.class) > @RunAsClient > public class FristenTest extends TestDeployments { > @ArquillianResource > private URL contextPath; > @Drone > private WebDriver driver; > @Page > private LoginPage loginPage; > @Page > private HomePage homePage; > @Page > private BenutzerdatenHomePage benutzerdatenHomePage; > @Page > private FristenPage fristenPage; > @Test > public void PageAccessTest(@InitialPage LoginPage loginP) { > loginP.loginWithCredentials("admin", "gip123"); > homePage.getNavigationBar().navigateToUserData(); > benutzerdatenHomePage.getMenu().openFristen(); > assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); > } > {code} > And if i run this test, i get a PageObjectInitializationException -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 08:35:00 2015 From: issues at jboss.org (Robert Hoeppner (JIRA)) Date: Thu, 1 Oct 2015 08:35:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Hoeppner updated ARQGRA-481: ----------------------------------- Description: I have an abstract PageObject like these: {code:java} public abstract class AbstractBenutzerdatenPageWithEdit extends AbstractBenutzerdatenPage { @FindBy(id = "browser:editDialog:dlg_container") private EDITDLG editDialog; public EDITDLG getEditDialog() { return editDialog; } } {code} AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: {code:java} @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") public class FristenPage extends AbstractBenutzerdatenPageWithEdit { ..... } {code} at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment {code:java} public class FristenEditDialogFragment extends AbstractEditDialogFragment { ... } {code} The test looking like these: {code:java} @RunWith(Arquillian.class) @RunAsClient public class FristenTest extends TestDeployments { @ArquillianResource private URL contextPath; @Drone private WebDriver driver; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private BenutzerdatenHomePage benutzerdatenHomePage; @Page private FristenPage fristenPage; @Test public void PageAccessTest(@InitialPage LoginPage loginP) { loginP.loginWithCredentials("admin", "gip123"); homePage.getNavigationBar().navigateToUserData(); benutzerdatenHomePage.getMenu().openFristen(); assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); } {code} And if i run this test, i get a PageObjectInitializationException was: I have an abstract PageObject like these: {code:java} public abstract class AbstractBenutzerdatenPageWithEdit extends AbstractBenutzerdatenPage { @FindBy(id = "browser:editDialog:dlg_container") private EDITDLG editDialog; public EDITDLG getEditDialog() { return editDialog; } } {code} AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: {code:java} @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") public class FristenPage extends AbstractBenutzerdatenPageWithEdit { .... public FristenDetailFragment getDetail() { return detail; } ..... } {code} at which FristenDetailFragment is one concrete implementation of AbstractEditDialogFragment The test looking like these {code:java} @RunWith(Arquillian.class) @RunAsClient public class FristenTest extends TestDeployments { @ArquillianResource private URL contextPath; @Drone private WebDriver driver; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private BenutzerdatenHomePage benutzerdatenHomePage; @Page private FristenPage fristenPage; @Test public void PageAccessTest(@InitialPage LoginPage loginP) { loginP.loginWithCredentials("admin", "gip123"); homePage.getNavigationBar().navigateToUserData(); benutzerdatenHomePage.getMenu().openFristen(); assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); } {code} And if i run this test, i get a PageObjectInitializationException > generic attribute injection doesn't work > ---------------------------------------- > > Key: ARQGRA-481 > URL: https://issues.jboss.org/browse/ARQGRA-481 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final > Environment: OS: Win7 > Java: 1.7.0_17 > AS: Wildfly 8.2.0.final > Reporter: Robert Hoeppner > Attachments: stacktrace.txt > > > I have an abstract PageObject like these: > {code:java} > public abstract class AbstractBenutzerdatenPageWithEdit extends > AbstractBenutzerdatenPage { > @FindBy(id = "browser:editDialog:dlg_container") > private EDITDLG editDialog; > public EDITDLG getEditDialog() { > return editDialog; > } > } > {code} > AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: > {code:java} > @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") > public class FristenPage extends AbstractBenutzerdatenPageWithEdit { > ..... > } > {code} > at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment > {code:java} > public class FristenEditDialogFragment extends AbstractEditDialogFragment { > ... > } > {code} > The test looking like these: > {code:java} > @RunWith(Arquillian.class) > @RunAsClient > public class FristenTest extends TestDeployments { > @ArquillianResource > private URL contextPath; > @Drone > private WebDriver driver; > @Page > private LoginPage loginPage; > @Page > private HomePage homePage; > @Page > private BenutzerdatenHomePage benutzerdatenHomePage; > @Page > private FristenPage fristenPage; > @Test > public void PageAccessTest(@InitialPage LoginPage loginP) { > loginP.loginWithCredentials("admin", "gip123"); > homePage.getNavigationBar().navigateToUserData(); > benutzerdatenHomePage.getMenu().openFristen(); > assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); > } > {code} > And if i run this test, i get a PageObjectInitializationException -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 08:37:00 2015 From: issues at jboss.org (Robert Hoeppner (JIRA)) Date: Thu, 1 Oct 2015 08:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Hoeppner updated ARQGRA-481: ----------------------------------- Description: I have an abstract PageObject like these: {code:java} public abstract class AbstractBenutzerdatenPageWithEdit extends AbstractBenutzerdatenPage { @FindBy(id = "browser:editDialog:dlg_container") private EDITDLG editDialog; public EDITDLG getEditDialog() { return editDialog; } } {code} AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: {code:java} @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") public class FristenPage extends AbstractBenutzerdatenPageWithEdit { ..... } {code} at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment {code:java} public class FristenEditDialogFragment extends AbstractEditDialogFragment { ... } {code} The test looking like these: {code:java} @RunWith(Arquillian.class) @RunAsClient public class FristenTest extends TestDeployments { @ArquillianResource private URL contextPath; @Drone private WebDriver driver; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private BenutzerdatenHomePage benutzerdatenHomePage; @Page private FristenPage fristenPage; @Test public void PageAccessTest(@InitialPage LoginPage loginP) { loginP.loginWithCredentials("admin", "gip123"); homePage.getNavigationBar().navigateToUserData(); benutzerdatenHomePage.getMenu().openFristen(); assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); } {code} And if i run this test, i get a PageObjectInitializationException {code} org.jboss.arquillian.graphene.enricher.exception.PageObjectInitializationException: Can not instantiate Page Object class de.gipmbh.absenz.web.pageModel.benutzerdaten.FristenPage declared in: de.gipmbh.absenz.web.uitests.benutzerdaten.FristenTest {code} was: I have an abstract PageObject like these: {code:java} public abstract class AbstractBenutzerdatenPageWithEdit extends AbstractBenutzerdatenPage { @FindBy(id = "browser:editDialog:dlg_container") private EDITDLG editDialog; public EDITDLG getEditDialog() { return editDialog; } } {code} AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: {code:java} @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") public class FristenPage extends AbstractBenutzerdatenPageWithEdit { ..... } {code} at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment {code:java} public class FristenEditDialogFragment extends AbstractEditDialogFragment { ... } {code} The test looking like these: {code:java} @RunWith(Arquillian.class) @RunAsClient public class FristenTest extends TestDeployments { @ArquillianResource private URL contextPath; @Drone private WebDriver driver; @Page private LoginPage loginPage; @Page private HomePage homePage; @Page private BenutzerdatenHomePage benutzerdatenHomePage; @Page private FristenPage fristenPage; @Test public void PageAccessTest(@InitialPage LoginPage loginP) { loginP.loginWithCredentials("admin", "gip123"); homePage.getNavigationBar().navigateToUserData(); benutzerdatenHomePage.getMenu().openFristen(); assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); } {code} And if i run this test, i get a PageObjectInitializationException > generic attribute injection doesn't work > ---------------------------------------- > > Key: ARQGRA-481 > URL: https://issues.jboss.org/browse/ARQGRA-481 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final > Environment: OS: Win7 > Java: 1.7.0_17 > AS: Wildfly 8.2.0.final > Reporter: Robert Hoeppner > Attachments: stacktrace.txt > > > I have an abstract PageObject like these: > {code:java} > public abstract class AbstractBenutzerdatenPageWithEdit extends > AbstractBenutzerdatenPage { > @FindBy(id = "browser:editDialog:dlg_container") > private EDITDLG editDialog; > public EDITDLG getEditDialog() { > return editDialog; > } > } > {code} > AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: > {code:java} > @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") > public class FristenPage extends AbstractBenutzerdatenPageWithEdit { > ..... > } > {code} > at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment > {code:java} > public class FristenEditDialogFragment extends AbstractEditDialogFragment { > ... > } > {code} > The test looking like these: > {code:java} > @RunWith(Arquillian.class) > @RunAsClient > public class FristenTest extends TestDeployments { > @ArquillianResource > private URL contextPath; > @Drone > private WebDriver driver; > @Page > private LoginPage loginPage; > @Page > private HomePage homePage; > @Page > private BenutzerdatenHomePage benutzerdatenHomePage; > @Page > private FristenPage fristenPage; > @Test > public void PageAccessTest(@InitialPage LoginPage loginP) { > loginP.loginWithCredentials("admin", "gip123"); > homePage.getNavigationBar().navigateToUserData(); > benutzerdatenHomePage.getMenu().openFristen(); > assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); > } > {code} > And if i run this test, i get a PageObjectInitializationException > {code} > org.jboss.arquillian.graphene.enricher.exception.PageObjectInitializationException: Can not instantiate Page Object > class de.gipmbh.absenz.web.pageModel.benutzerdaten.FristenPage > declared in: > de.gipmbh.absenz.web.uitests.benutzerdaten.FristenTest > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 1 12:25:00 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Thu, 1 Oct 2015 12:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: Alexandros Trifyllis created ARQ-1986: ----------------------------------------- Summary: 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) From issues at jboss.org Thu Oct 1 12:36:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 1 Oct 2015 12:36:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114279#comment-13114279 ] Aslak Knutsen commented on ARQ-1986: ------------------------------------ It seems unless the MANIFEST.MF file contain a Manifest-Version, all Attributes will be ignored when written to a stream . The underlying class used here is from the JDK; java.util.jar.Manifest Does adding a version solve your issues? > 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) From issues at jboss.org Thu Oct 1 12:45:01 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Thu, 1 Oct 2015 12:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114281#comment-13114281 ] Alexandros Trifyllis commented on ARQ-1986: ------------------------------------------- Yes this is the MANIFEST.MF I am using: Manifest-Version: 1.0 Built-by: username Built-Jdk: 1.8.0_31 Created-By: ShrinkWrap Maven Resolver Dependencies: org.apache.ws.security,org.apache.cxf,org.apache.cxf.impl,org.jboss.ws.cxf.jbossws-cxf-client > 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) From issues at jboss.org Thu Oct 1 13:17:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 1 Oct 2015 13:17:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114292#comment-13114292 ] Aslak Knutsen commented on ARQ-1986: ------------------------------------ Odd, running that through the Jacoco code seems to work just fine. The Dependencies line is reformatted to max 80 char, but beyond that it seems all good. Could you try adding the MANIFEST.MF file via addAsManifestResource(new File("src/main/java/MEtA-INF/MANIFEST.MF")) instead of via the ClassLoader (String overloaded version). Just in case it's actually finding some 'other' MANIFEST.MF file? > 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) From issues at jboss.org Thu Oct 1 13:18:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 1 Oct 2015 13:18:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114292#comment-13114292 ] Aslak Knutsen edited comment on ARQ-1986 at 10/1/15 1:17 PM: ------------------------------------------------------------- Odd, running that through the Jacoco code seems to work just fine. The Dependencies line is reformatted to max 80 char, but beyond that it seems all good. Could you try adding the MANIFEST.MF file via addAsManifestResource(new File("src/main/java/META-INF/MANIFEST.MF")) instead of via the ClassLoader (String overloaded version). Just in case it's actually finding some 'other' MANIFEST.MF file? was (Author: aslak): Odd, running that through the Jacoco code seems to work just fine. The Dependencies line is reformatted to max 80 char, but beyond that it seems all good. Could you try adding the MANIFEST.MF file via addAsManifestResource(new File("src/main/java/MEtA-INF/MANIFEST.MF")) instead of via the ClassLoader (String overloaded version). Just in case it's actually finding some 'other' MANIFEST.MF file? > 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) From issues at jboss.org Fri Oct 2 01:53:00 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Fri, 2 Oct 2015 01:53:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114374#comment-13114374 ] Alexandros Trifyllis commented on ARQ-1986: ------------------------------------------- Yes this is working now. Thank you Aslak! > 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) From issues at jboss.org Fri Oct 2 02:10:00 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Fri, 2 Oct 2015 02:10:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114374#comment-13114374 ] Alexandros Trifyllis edited comment on ARQ-1986 at 10/2/15 2:09 AM: -------------------------------------------------------------------- Yes this is working now. Thank you Aslak! EDIT: I was wrong, the MANIFEST.MF in the final war is: Manifest-Version: 1.0 Built-by: trifyllalex Built-Jdk: 1.8.0_31 Created-By: ShrinkWrap Maven Resolver So it seems to strip down the Dependencies line was (Author: otinanism): Yes this is working now. Thank you Aslak! > 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) From issues at jboss.org Fri Oct 2 06:16:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 2 Oct 2015 06:16:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114489#comment-13114489 ] Aslak Knutsen commented on ARQ-1986: ------------------------------------ Hmm, but why Created-By ShrinkWrap Resolver.. > 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) From issues at jboss.org Fri Oct 2 06:28:00 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Fri, 2 Oct 2015 06:28:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114501#comment-13114501 ] Alexandros Trifyllis commented on ARQ-1986: ------------------------------------------- Oh never mind that, this is because the original MANIFEST.MF that I am including in the war contains this line.. Sorry about that, this is confusing. > 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) From issues at jboss.org Fri Oct 2 16:35:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 2 Oct 2015 16:35:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114766#comment-13114766 ] Luk?? Fry? commented on ARQGRA-480: ----------------------------------- I can see two issues reported as one: a) configuration doesn't work as expected (as indicated by printed configuration summary) b) you suggest enhancing the behavior by making it more "smart" (either (1) or (2)), but I can see one can already achieve the desired solution by expressing when he wants to take screenshots I would suggest to leave configuration options as they are but making them follow the arquillian.xml configuration (no additional activation logic). > Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-480 > URL: https://issues.jboss.org/browse/ARQGRA-480 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > Consider this scenario: > Arquillian.xml contains: > {code:xml} > > true > false > false > false > > {code} > Then, when the test starts this output is written there in the console log: > {noformat} > Configuration of Arquillian Browser Screenshooter: > rootDir target/screenshots > screenshotType PNG > takeBeforeTest true > takeAfterTest false > takeWhenTestFailed false > takeOnEveryAction true > {noformat} > There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. > The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: > 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase > 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 4 11:41:00 2015 From: issues at jboss.org (Christian Schlichtherle (JIRA)) Date: Sun, 4 Oct 2015 11:41:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1987) Arquillian doesn't work with latest Tomcat 7.0.64 and 8.0.27 due to class loader issues In-Reply-To: References: Message-ID: Christian Schlichtherle created ARQ-1987: -------------------------------------------- Summary: Arquillian doesn't work with latest Tomcat 7.0.64 and 8.0.27 due to class loader issues Key: ARQ-1987 URL: https://issues.jboss.org/browse/ARQ-1987 Project: Arquillian Issue Type: Bug Components: Tomcat Containers Affects Versions: 1.1.9.Final Environment: {code} $ JAVA_HOME=`/usr/libexec/java_home -v 1.7` mvn --version Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00) Maven home: /usr/local/Cellar/maven/3.3.3/libexec Java version: 1.7.0_80, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "10.11", arch: "x86_64", family: "mac" {code} Reporter: Christian Schlichtherle Priority: Blocker I am following the reference documentation for testing with an embedded Tomcat 7 container at https://docs.jboss.org/author/display/ARQ/Tomcat+7.0+-+Embedded . This works fine with Tomcat 7.0.50. However, when updating to Tomcat 7.0.64 and leaving all else unchanged, I get this when running my integration test: {code} /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/bin/java -ea -Djava.awt.headless=true -Didea.launcher.port=7540 "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA 14.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath "/Applications/IntelliJ IDEA 14.app/Contents/lib/idea_rt.jar:/Applications/IntelliJ IDEA 14.app/Contents/plugins/junit/lib/junit-rt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/javafx-doclet.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/htmlconverter.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Users/christian/projects/trueupdate/trueupdate-installer/trueupdate-installer-tomcat/target/test-classes:/Users/christian/projects/trueupdate/trueupdate-installer/trueupdate-installer-tomcat/target/classes:/Users/christian/projects/trueupdate/trueupdate-installer/trueupdate-installer-core/target/classes:/Users/christian/projects/trueupdate/trueupdate-core/target/classes:/Users/christian/projects/trueupdate/trueupdate-util/target/classes:/Users/christian/projects/trueupdate/trueupdate-manager/trueupdate-manager-spec/target/classes:/Users/christian/projects/trueupdate/trueupdate-message/target/classes:/Users/christian/projects/trueupdate/trueupdate-artifact/trueupdate-artifact-spec/target/classes:/Users/christian/.m2/repository/org/jboss/arquillian/junit/arquillian-junit-container/1.1.5.Final/arquillian-junit-container-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/junit/arquillian-junit-core/1.1.5.Final/arquillian-junit-core-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/test/arquillian-test-api/1.1.5.Final/arquillian-test-api-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/core/arquillian-core-api/1.1.5.Final/arquillian-core-api-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/test/arquillian-test-spi/1.1.5.Final/arquillian-test-spi-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/core/arquillian-core-spi/1.1.5.Final/arquillian-core-spi-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/container/arquillian-container-test-api/1.1.5.Final/arquillian-container-test-api-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.2/shrinkwrap-api-1.2.2.jar:/Users/christian/.m2/repository/org/jboss/arquillian/container/arquillian-container-test-spi/1.1.5.Final/arquillian-container-test-spi-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/core/arquillian-core-impl-base/1.1.5.Final/arquillian-core-impl-base-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/test/arquillian-test-impl-base/1.1.5.Final/arquillian-test-impl-base-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/container/arquillian-container-impl-base/1.1.5.Final/arquillian-container-impl-base-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/config/arquillian-config-api/1.1.5.Final/arquillian-config-api-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/config/arquillian-config-impl-base/1.1.5.Final/arquillian-config-impl-base-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0-alpha-5/shrinkwrap-descriptors-spi-2.0.0-alpha-5.jar:/Users/christian/.m2/repository/org/easytesting/fest-assert/1.4/fest-assert-1.4.jar:/Users/christian/.m2/repository/org/easytesting/fest-util/1.1.6/fest-util-1.1.6.jar:/Users/christian/.m2/repository/org/jboss/arquillian/container/arquillian-container-test-impl-base/1.1.5.Final/arquillian-container-test-impl-base-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.2/shrinkwrap-impl-base-1.2.2.jar:/Users/christian/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.2/shrinkwrap-spi-1.2.2.jar:/Users/christian/.m2/repository/org/jboss/arquillian/container/arquillian-tomcat-embedded-7/1.0.0.CR6/arquillian-tomcat-embedded-7-1.0.0.CR6.jar:/Users/christian/.m2/repository/org/jboss/arquillian/container/arquillian-container-spi/1.1.5.Final/arquillian-container-spi-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0-alpha-5/shrinkwrap-descriptors-api-base-2.0.0-alpha-5.jar:/Users/christian/.m2/repository/org/jboss/arquillian/protocol/arquillian-protocol-servlet/1.1.5.Final/arquillian-protocol-servlet-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/testenricher/arquillian-testenricher-cdi/1.1.5.Final/arquillian-testenricher-cdi-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/testenricher/arquillian-testenricher-resource/1.1.5.Final/arquillian-testenricher-resource-1.1.5.Final.jar:/Users/christian/.m2/repository/org/jboss/arquillian/testenricher/arquillian-testenricher-initialcontext/1.1.5.Final/arquillian-testenricher-initialcontext-1.1.5.Final.jar:/Users/christian/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/7.0.64/tomcat-embed-core-7.0.64.jar:/Users/christian/.m2/repository/org/apache/tomcat/embed/tomcat-embed-jasper/7.0.64/tomcat-embed-jasper-7.0.64.jar:/Users/christian/.m2/repository/org/apache/tomcat/embed/tomcat-embed-el/7.0.64/tomcat-embed-el-7.0.64.jar:/Users/christian/.m2/repository/org/eclipse/jdt/core/compiler/ecj/4.4.2/ecj-4.4.2.jar:/Users/christian/.m2/repository/org/apache/tomcat/embed/tomcat-embed-logging-juli/7.0.64/tomcat-embed-logging-juli-7.0.64.jar:/Users/christian/.m2/repository/com/google/code/findbugs/annotations/3.0.0/annotations-3.0.0.jar:/Users/christian/.m2/repository/junit/junit/4.12/junit-4.12.jar:/Users/christian/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar:/Users/christian/.m2/repository/org/mockito/mockito-core/1.10.17/mockito-core-1.10.17.jar:/Users/christian/.m2/repository/org/objenesis/objenesis/2.1/objenesis-2.1.jar:/Users/christian/.m2/repository/org/scalatest/scalatest_2.11/2.2.3/scalatest_2.11-2.2.3.jar:/Users/christian/.m2/repository/org/scala-lang/scala-library/2.11.4/scala-library-2.11.4.jar:/Users/christian/.m2/repository/org/scala-lang/scala-reflect/2.11.2/scala-reflect-2.11.2.jar:/Users/christian/.m2/repository/org/scala-lang/modules/scala-xml_2.11/1.0.2/scala-xml_2.11-1.0.2.jar:/Users/christian/.m2/repository/org/scalacheck/scalacheck_2.11/1.12.1/scalacheck_2.11-1.12.1.jar:/Users/christian/.m2/repository/org/scala-lang/modules/scala-parser-combinators_2.11/1.0.2/scala-parser-combinators_2.11-1.0.2.jar:/Users/christian/.m2/repository/org/scala-sbt/test-interface/1.0/test-interface-1.0.jar" com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 net.java.trueupdate.installer.tomcat.TomcatUpdateInstallerIT Okt 04, 2015 5:18:31 PM org.apache.coyote.AbstractProtocol init INFORMATION: Initializing ProtocolHandler ["http-bio-1971"] Okt 04, 2015 5:18:31 PM org.apache.catalina.core.StandardService startInternal INFORMATION: Starting service arquillian-tomcat-embedded-7 Okt 04, 2015 5:18:31 PM org.apache.catalina.core.StandardEngine startInternal INFORMATION: Starting Servlet Engine: Apache Tomcat/7.0.64 Okt 04, 2015 5:18:31 PM org.apache.coyote.AbstractProtocol start INFORMATION: Starting ProtocolHandler ["http-bio-1971"] Okt 04, 2015 5:18:32 PM org.apache.catalina.startup.HostConfig deployWAR INFORMATION: Deploying web application archive /private/var/folders/qb/9yzsm8_13wq7mxsf8k0z98h40000gp/T/tomcat-embedded-73699509114599265821.tmp/webapps/3bc039ea-042f-4668-a75b-5f1424e3fdf4.war Okt 04, 2015 5:18:32 PM org.apache.catalina.startup.ContextConfig getDefaultWebXmlFragment INFORMATION: No global web.xml found Okt 04, 2015 5:18:33 PM org.apache.catalina.startup.TldConfig execute INFORMATION: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. Okt 04, 2015 5:18:33 PM org.apache.catalina.startup.HostConfig deployWAR INFORMATION: Deployment of web application archive /private/var/folders/qb/9yzsm8_13wq7mxsf8k0z98h40000gp/T/tomcat-embedded-73699509114599265821.tmp/webapps/3bc039ea-042f-4668-a75b-5f1424e3fdf4.war has finished in 1,811 ms java.lang.ExceptionInInitializerError at org.jboss.shrinkwrap.api.ShrinkWrap.getDefaultDomain(ShrinkWrap.java:108) at org.jboss.shrinkwrap.api.ShrinkWrap.create(ShrinkWrap.java:136) at net.java.trueupdate.installer.tomcat.TomcatUpdateInstallerIT$.testArchive(TomcatUpdateInstallerIT.scala:59) at net.java.trueupdate.installer.tomcat.TomcatUpdateInstallerIT.test(TomcatUpdateInstallerIT.scala:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:301) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.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 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:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.createTestContext(TestContextHandler.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 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:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89) at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.ClassCastException: Incorrect expected type, org.jboss.shrinkwrap.api.ExtensionLoader, defined for org.jboss.shrinkwrap.impl.base.ServiceExtensionLoader at org.jboss.shrinkwrap.api.SecurityActions.newInstance(SecurityActions.java:143) at org.jboss.shrinkwrap.api.ConfigurationBuilder.createDefaultExtensionLoader(ConfigurationBuilder.java:230) at org.jboss.shrinkwrap.api.ConfigurationBuilder.setDefaults(ConfigurationBuilder.java:204) at org.jboss.shrinkwrap.api.Configuration.(Configuration.java:81) at org.jboss.shrinkwrap.api.ConfigurationBuilder.build(ConfigurationBuilder.java:156) at org.jboss.shrinkwrap.api.ShrinkWrap.createDomain(ShrinkWrap.java:79) at org.jboss.shrinkwrap.api.ShrinkWrap.createDomain(ShrinkWrap.java:60) at org.jboss.shrinkwrap.api.ShrinkWrap$DefaultDomainWrapper.(ShrinkWrap.java:204) at org.jboss.shrinkwrap.api.ShrinkWrap$DefaultDomainWrapper.(ShrinkWrap.java:199) ... 94 more Okt 04, 2015 5:18:34 PM org.apache.coyote.AbstractProtocol pause INFORMATION: Pausing ProtocolHandler ["http-bio-1971"] Okt 04, 2015 5:18:34 PM org.apache.catalina.core.StandardService stopInternal INFORMATION: Stopping service arquillian-tomcat-embedded-7 Okt 04, 2015 5:18:34 PM org.apache.coyote.AbstractProtocol stop INFORMATION: Stopping ProtocolHandler ["http-bio-1971"] Process finished with exit code 255 {code} The relevant code in {{SecurityActions.newInstance}} is this: {code} try { return expectedType.cast(obj); } catch (final ClassCastException cce) { // Reconstruct so we get some useful information throw new ClassCastException("Incorrect expected type, " + expectedType.getName() + ", defined for " + obj.getClass().getName()); } {code} I've set a break point at line line 143, which is the {{throws}}-statement to verify that {{obj}} is loaded by a different class loader than the class loader of {{expectedType}}, which is why a {{ClassCastException}} is thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 5 15:21:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 5 Oct 2015 15:21:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115191#comment-13115191 ] Aslak Knutsen commented on ARQ-1986: ------------------------------------ Which container are you running this on? > 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) From issues at jboss.org Mon Oct 5 16:00:01 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Mon, 5 Oct 2015 16:00:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115210#comment-13115210 ] Alexandros Trifyllis commented on ARQ-1986: ------------------------------------------- Wildfly 8.2.0, remote > 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) From issues at jboss.org Tue Oct 6 05:11:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 6 Oct 2015 05:11:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115301#comment-13115301 ] Aslak Knutsen commented on ARQ-1986: ------------------------------------ Strange. I can't seem to replicate this behavior. Could you provide the pom.xml file you're using? > 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) From issues at jboss.org Tue Oct 6 08:41:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 6 Oct 2015 08:41:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115415#comment-13115415 ] Matous Jobanek commented on ARQGRA-480: --------------------------------------- I completely agree. Here is my suggestion: https://github.com/MatousJobanek/arquillian-graphene/commit/6c1434d1c72858008ce40bd939aa5b3845111202 > Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-480 > URL: https://issues.jboss.org/browse/ARQGRA-480 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > Consider this scenario: > Arquillian.xml contains: > {code:xml} > > true > false > false > false > > {code} > Then, when the test starts this output is written there in the console log: > {noformat} > Configuration of Arquillian Browser Screenshooter: > rootDir target/screenshots > screenshotType PNG > takeBeforeTest true > takeAfterTest false > takeWhenTestFailed false > takeOnEveryAction true > {noformat} > There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. > The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: > 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase > 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 6 09:06:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 6 Oct 2015 09:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-482) Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called In-Reply-To: References: Message-ID: Matous Jobanek created ARQGRA-482: ------------------------------------- Summary: Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called Key: ARQGRA-482 URL: https://issues.jboss.org/browse/ARQGRA-482 Project: Arquillian Graphene Issue Type: Bug Components: screenshooter Affects Versions: 2.1.0.Alpha2 Reporter: Matous Jobanek Fix For: 2.1-Tracking When takeOnEveryAction is activated and either {{WebDriver.close()}} or {{WebDriver.quit()}} is called, then this exception is thrown: {noformat} java.lang.RuntimeException: Error during saving the screenshot! at org.arquillian.extension.recorder.screenshooter.browser.impl.BrowserScreenshooter.takeScreenshot(BrowserScreenshooter.java:126) at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotAndReportService.takeScreenshotAndReport(TakeScreenshotAndReportService.java:60) at org.arquillian.extension.recorder.screenshooter.browser.impl.AbstractTakeScreenshotInterceptor.takeScreenshotAndReport(AbstractTakeScreenshotInterceptor.java:46) at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotOnEveryActionInterceptor.intercept(TakeScreenshotOnEveryActionInterceptor.java:75) at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) at org.openqa.selenium.phantomjs.PhantomJSDriver$$EnhancerByGraphene$$8a745fde.close() at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase$OnEveryActionManyActionsTestClass.testMethod(OnEveryActionScreenshotTestCase.java:135) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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:145) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) 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:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.junit.runners.Suite.runChild(Suite.java:127) at org.junit.runners.Suite.runChild(Suite.java:26) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:138) at org.junit.runner.JUnitCore.run(JUnitCore.java:128) at org.junit.runner.JUnitCore.runClasses(JUnitCore.java:73) at org.jboss.arquillian.graphene.screenshooter.ftest.when.AbstractScreenshotTestCase.runTest(AbstractScreenshotTestCase.java:53) at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase.onEveryActionManyActionsTest(OnEveryActionScreenshotTestCase.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) 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 org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) Caused by: org.openqa.selenium.NoSuchWindowException: {"errorMessage":"Currently Window handle/name is invalid (closed?)","request":{"headers":{"Accept-Encoding":"gzip,deflate","Cache-Control":"no-cache","Connection":"Keep-Alive","Host":"localhost:8148","User-Agent":"Apache-HttpClient/4.4.1 (Java/1.8.0_05)"},"httpVersion":"1.1","method":"GET","url":"/screenshot","urlParsed":{"anchor":"","query":"","file":"screenshot","directory":"/","path":"/screenshot","relative":"/screenshot","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/screenshot","queryKey":{},"chunks":["screenshot"]},"urlOriginal":"/session/a57ad390-6c28-11e5-b917-2bceae0d5451/screenshot"}} Command duration or timeout: 48 milliseconds {noformat} This behaviour is expected, because there nothing where the screenshot could be taken. Solution is to remove these two methods from the allowed list. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 6 09:19:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 6 Oct 2015 09:19:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115415#comment-13115415 ] Matous Jobanek edited comment on ARQGRA-480 at 10/6/15 9:18 AM: ---------------------------------------------------------------- I completely agree. Here is my suggestion: https://github.com/arquillian/arquillian-graphene/pull/140 was (Author: mjobanek): I completely agree. Here is my suggestion: https://github.com/MatousJobanek/arquillian-graphene/commit/6c1434d1c72858008ce40bd939aa5b3845111202 > Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-480 > URL: https://issues.jboss.org/browse/ARQGRA-480 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > Consider this scenario: > Arquillian.xml contains: > {code:xml} > > true > false > false > false > > {code} > Then, when the test starts this output is written there in the console log: > {noformat} > Configuration of Arquillian Browser Screenshooter: > rootDir target/screenshots > screenshotType PNG > takeBeforeTest true > takeAfterTest false > takeWhenTestFailed false > takeOnEveryAction true > {noformat} > There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. > The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: > 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase > 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 6 09:20:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 6 Oct 2015 09:20:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQGRA-480: ---------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/140 > Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-480 > URL: https://issues.jboss.org/browse/ARQGRA-480 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > Consider this scenario: > Arquillian.xml contains: > {code:xml} > > true > false > false > false > > {code} > Then, when the test starts this output is written there in the console log: > {noformat} > Configuration of Arquillian Browser Screenshooter: > rootDir target/screenshots > screenshotType PNG > takeBeforeTest true > takeAfterTest false > takeWhenTestFailed false > takeOnEveryAction true > {noformat} > There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. > The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: > 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase > 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 7 02:11:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 7 Oct 2015 02:11:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-482) Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQGRA-482: ---------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/141 > Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called > ----------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-482 > URL: https://issues.jboss.org/browse/ARQGRA-482 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Fix For: 2.1-Tracking > > > When takeOnEveryAction is activated and either {{WebDriver.close()}} or {{WebDriver.quit()}} is called, then this exception is thrown: > {noformat} > java.lang.RuntimeException: Error during saving the screenshot! > at org.arquillian.extension.recorder.screenshooter.browser.impl.BrowserScreenshooter.takeScreenshot(BrowserScreenshooter.java:126) > at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotAndReportService.takeScreenshotAndReport(TakeScreenshotAndReportService.java:60) > at org.arquillian.extension.recorder.screenshooter.browser.impl.AbstractTakeScreenshotInterceptor.takeScreenshotAndReport(AbstractTakeScreenshotInterceptor.java:46) > at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotOnEveryActionInterceptor.intercept(TakeScreenshotOnEveryActionInterceptor.java:75) > at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) > at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) > at org.openqa.selenium.phantomjs.PhantomJSDriver$$EnhancerByGraphene$$8a745fde.close() > at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase$OnEveryActionManyActionsTestClass.testMethod(OnEveryActionScreenshotTestCase.java:135) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at org.junit.runner.JUnitCore.run(JUnitCore.java:128) > at org.junit.runner.JUnitCore.runClasses(JUnitCore.java:73) > at org.jboss.arquillian.graphene.screenshooter.ftest.when.AbstractScreenshotTestCase.runTest(AbstractScreenshotTestCase.java:53) > at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase.onEveryActionManyActionsTest(OnEveryActionScreenshotTestCase.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > 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 org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.openqa.selenium.NoSuchWindowException: {"errorMessage":"Currently Window handle/name is invalid (closed?)","request":{"headers":{"Accept-Encoding":"gzip,deflate","Cache-Control":"no-cache","Connection":"Keep-Alive","Host":"localhost:8148","User-Agent":"Apache-HttpClient/4.4.1 (Java/1.8.0_05)"},"httpVersion":"1.1","method":"GET","url":"/screenshot","urlParsed":{"anchor":"","query":"","file":"screenshot","directory":"/","path":"/screenshot","relative":"/screenshot","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/screenshot","queryKey":{},"chunks":["screenshot"]},"urlOriginal":"/session/a57ad390-6c28-11e5-b917-2bceae0d5451/screenshot"}} > Command duration or timeout: 48 milliseconds > {noformat} > This behaviour is expected, because there nothing where the screenshot could be taken. Solution is to remove these two methods from the allowed list. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 7 08:08:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 7 Oct 2015 08:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1988) Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1988: ---------------------------------- Summary: Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 Key: ARQ-1988 URL: https://issues.jboss.org/browse/ARQ-1988 Project: Arquillian Issue Type: Component Upgrade Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha7 Reporter: Aslak Knutsen Fix For: warp_1.0.0.Beta1 Warp needs to upgrade to HTTPCore 4.4.3 to be compatible with Drone 2.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 7 08:08:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 7 Oct 2015 08:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1988) Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1988: ------------------------------- Forum Reference: https://github.com/arquillian/arquillian-universe-bom/issues/14 > Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 > -------------------------------------------------------------- > > Key: ARQ-1988 > URL: https://issues.jboss.org/browse/ARQ-1988 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > > Warp needs to upgrade to HTTPCore 4.4.3 to be compatible with Drone 2.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 7 08:35:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 7 Oct 2015 08:35:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1988) Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1988: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-warp/pull/30 > Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 > -------------------------------------------------------------- > > Key: ARQ-1988 > URL: https://issues.jboss.org/browse/ARQ-1988 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > > Warp needs to upgrade to HTTPCore 4.4.3 to be compatible with Drone 2.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 7 09:08:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 7 Oct 2015 09:08:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1989) Video-impl-base fail if no impl is on classpath In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1989: ---------------------------------- Summary: Video-impl-base fail if no impl is on classpath Key: ARQ-1989 URL: https://issues.jboss.org/browse/ARQ-1989 Project: Arquillian Issue Type: Enhancement Components: Extension - Recorder Affects Versions: recorder_1.1.0.Alpha3 Reporter: Aslak Knutsen {code} java.lang.NullPointerException at org.arquillian.extension.recorder.video.impl.VideoLifecycleObserver.beforeSuite(VideoLifecycleObserver.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) {code} With no Video Recorder Implementation on classpath the Video Impl fail. Even tho it has a DefaultVideoStrategy it can use, the registration of this service rely on the VideoExtensionConfigured event which is never fired if no Video impl is found on classpath. Attempting to read that strategy then fails with a NPE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 8 16:05:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 8 Oct 2015 16:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1990) Should not export tests classified dependencies in compile scope In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1990: ---------------------------------- Summary: Should not export tests classified dependencies in compile scope Key: ARQ-1990 URL: https://issues.jboss.org/browse/ARQ-1990 Project: Arquillian Issue Type: Bug Components: Extension - Recorder Affects Versions: recorder_1.1.0.Alpha3 Reporter: Aslak Knutsen Assignee: Aslak Knutsen -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 8 16:18:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 8 Oct 2015 16:18:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1990) Should not export tests classified dependencies in compile scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1990: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-recorder/pull/20 > Should not export tests classified dependencies in compile scope > ---------------------------------------------------------------- > > Key: ARQ-1990 > URL: https://issues.jboss.org/browse/ARQ-1990 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 8 16:28:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 8 Oct 2015 16:28:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1989) Video-impl-base fail if no impl is on classpath In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1989: ------------------------------- Fix Version/s: recorder_1.1.0.Alpha4 > Video-impl-base fail if no impl is on classpath > ----------------------------------------------- > > Key: ARQ-1989 > URL: https://issues.jboss.org/browse/ARQ-1989 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Aslak Knutsen > Fix For: recorder_1.1.0.Alpha4 > > > {code} > java.lang.NullPointerException > at org.arquillian.extension.recorder.video.impl.VideoLifecycleObserver.beforeSuite(VideoLifecycleObserver.java:93) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > {code} > With no Video Recorder Implementation on classpath the Video Impl fail. Even tho it has a DefaultVideoStrategy it can use, the registration of this service rely on the VideoExtensionConfigured event which is never fired if no Video impl is found on classpath. Attempting to read that strategy then fails with a NPE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 8 16:28:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 8 Oct 2015 16:28:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1990) Should not export tests classified dependencies in compile scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1990: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: recorder_1.1.0.Alpha4 Resolution: Done > Should not export tests classified dependencies in compile scope > ---------------------------------------------------------------- > > Key: ARQ-1990 > URL: https://issues.jboss.org/browse/ARQ-1990 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: recorder_1.1.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 8 16:30:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 8 Oct 2015 16:30:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1988) Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1988: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 > -------------------------------------------------------------- > > Key: ARQ-1988 > URL: https://issues.jboss.org/browse/ARQ-1988 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > > Warp needs to upgrade to HTTPCore 4.4.3 to be compatible with Drone 2.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 8 16:39:00 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Thu, 8 Oct 2015 16:39:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116654#comment-13116654 ] Alexandros Trifyllis commented on ARQ-1986: ------------------------------------------- I would try to recreate the issue with a simple pom because mine is quite complicated. If I can't recreate I will post the original one. > 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) From issues at jboss.org Fri Oct 9 12:23:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Oct 2015 12:23:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: Aslak Knutsen created ARQGRA-483: ------------------------------------ Summary: @Location might use the Wrong URL when used with Warp Key: ARQGRA-483 URL: https://issues.jboss.org/browse/ARQGRA-483 Project: Arquillian Graphene Issue Type: Bug Components: integration Affects Versions: 2.1.0.Alpha2 Reporter: Aslak Knutsen Both Graphene and Warp attempt to override the default Core URLResourceProvider. Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. Technically the two URLs used here could be different: {code} @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { } {code} BaseURL could be proxied and the URL used by InitialPage not, or the other way around. Graphene sets up it's ContextRootStore with which ever URL was provided last; https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 Core will do the opposite, which ever comes first. When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 9 12:36:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Oct 2015 12:36:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQGRA-483: --------------------------------- Description: Both Graphene and Warp attempt to override the default Core URLResourceProvider. Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. Technically the two URLs used here could be different: {code} @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { } {code} BaseURL could be proxied and the URL used by InitialPage not, or the other way around. Graphene sets up it's ContextRootStore with which ever URL was provided last; https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 Core will do the opposite, which ever comes first. When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. This seems to be a good test case currently: {code} @Drone private WebDriver driver; @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); } {code} Currently one will show 'proxy-port' and the other '8080'. This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. was: Both Graphene and Warp attempt to override the default Core URLResourceProvider. Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. Technically the two URLs used here could be different: {code} @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { } {code} BaseURL could be proxied and the URL used by InitialPage not, or the other way around. Graphene sets up it's ContextRootStore with which ever URL was provided last; https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 Core will do the opposite, which ever comes first. When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 9 14:42:00 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Fri, 9 Oct 2015 14:42:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: John Ament created ARQ-1991: ------------------------------- Summary: Weld EE embedded container leaks extension configuration Key: ARQ-1991 URL: https://issues.jboss.org/browse/ARQ-1991 Project: Arquillian Issue Type: Bug 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) From issues at jboss.org Fri Oct 9 14:46:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Oct 2015 14:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1991: ------------------------------- Affects Version/s: weld_1.0.0.CR9 > Weld EE embedded container leaks extension configuration > -------------------------------------------------------- > > Key: ARQ-1991 > URL: https://issues.jboss.org/browse/ARQ-1991 > Project: Arquillian > Issue Type: Bug > 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) From issues at jboss.org Fri Oct 9 14:46:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Oct 2015 14:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1991: ------------------------------- Component/s: Weld Containers > 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) From issues at jboss.org Fri Oct 9 14:50:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Oct 2015 14:50:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117137#comment-13117137 ] Aslak Knutsen commented on ARQ-1991: ------------------------------------ > I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. I would have expected the same, and I would assume the weld-core test suite would see a lot of strange behavior of that was not the case... Could you provide an example of 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) From issues at jboss.org Fri Oct 9 14:51:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 9 Oct 2015 14:51:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117137#comment-13117137 ] Aslak Knutsen edited comment on ARQ-1991 at 10/9/15 2:50 PM: ------------------------------------------------------------- > I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. I would have expected the same, and I would assume the weld-core test suite would see a lot of strange behavior if that was not the case... Could you provide an example of this? was (Author: aslak): > I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. I would have expected the same, and I would assume the weld-core test suite would see a lot of strange behavior of that was not the case... Could you provide an example of 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) From issues at jboss.org Fri Oct 9 20:20:00 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Fri, 9 Oct 2015 20:20:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117195#comment-13117195 ] 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/main/java/org/apache/deltaspike/core/util/ClassDeactivationUtils.java#L47 > 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) From issues at jboss.org Sat Oct 10 08:51:00 2015 From: issues at jboss.org (John Ament (JIRA)) Date: Sat, 10 Oct 2015 08:51:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Sat Oct 10 09:26:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sat, 10 Oct 2015 09:26:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Mon Oct 12 03:16:01 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Mon, 12 Oct 2015 03:16:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117251#comment-13117251 ] 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} 4.0.0 gr.dias mybank-parent 0.0.1-SNAPSHOT ../mybank-parent/pom.xml mybank-test mybank-test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-bom 2.2.0 pom import org.jboss.arquillian arquillian-bom 1.1.8.Final pom import javax javaee-api provided gr.dias mybank-ws ${project.version} classes test org.jboss.arquillian.junit arquillian-junit-container test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-depchain pom test org.wildfly.arquillian wildfly-arquillian-container-remote 1.0.0.CR1 test org.apache.cxf cxf-rt-frontend-simple org.jboss.ws.cxf jbossws-cxf-client test jboss-logging org.jboss.logging asm asm org.jacoco org.jacoco.core 0.7.4.201502262128 test maven-war-plugin 2.6 ../mybank-generated/src/main/resources src/test/resources {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) From issues at jboss.org Mon Oct 12 05:52:00 2015 From: issues at jboss.org (Alexandros Trifyllis (JIRA)) Date: Mon, 12 Oct 2015 05:52:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117251#comment-13117251 ] 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} 4.0.0 gr.dias mybank-parent 0.0.1-SNAPSHOT ../mybank-parent/pom.xml mybank-test mybank-test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-bom 2.2.0 pom import org.jboss.arquillian arquillian-bom 1.1.8.Final pom import javax javaee-api provided gr.dias mybank-ws ${project.version} classes test org.jboss.arquillian.junit arquillian-junit-container test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-depchain pom test org.wildfly.arquillian wildfly-arquillian-container-remote 1.0.0.CR1 test org.apache.cxf cxf-rt-frontend-simple org.jboss.ws.cxf jbossws-cxf-client test jboss-logging org.jboss.logging asm asm org.jboss.arquillian.extension arquillian-jacoco 1.0.0.Alpha8 test org.jacoco org.jacoco.core 0.7.4.201502262128 test maven-war-plugin 2.6 ../mybank-generated/src/main/resources src/test/resources {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} 4.0.0 gr.dias mybank-parent 0.0.1-SNAPSHOT ../mybank-parent/pom.xml mybank-test mybank-test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-bom 2.2.0 pom import org.jboss.arquillian arquillian-bom 1.1.8.Final pom import javax javaee-api provided gr.dias mybank-ws ${project.version} classes test org.jboss.arquillian.junit arquillian-junit-container test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-depchain pom test org.wildfly.arquillian wildfly-arquillian-container-remote 1.0.0.CR1 test org.apache.cxf cxf-rt-frontend-simple org.jboss.ws.cxf jbossws-cxf-client test jboss-logging org.jboss.logging asm asm org.jacoco org.jacoco.core 0.7.4.201502262128 test maven-war-plugin 2.6 ../mybank-generated/src/main/resources src/test/resources {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) From issues at jboss.org Wed Oct 14 05:10:00 2015 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 14 Oct 2015 05:10:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: 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) From issues at jboss.org Wed Oct 14 05:12:00 2015 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 14 Oct 2015 05:12:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Wed Oct 14 06:42:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 14 Oct 2015 06:42:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1340) Drone webdriver is not created during @BeforeClass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) From issues at jboss.org Wed Oct 14 06:45:01 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 14 Oct 2015 06:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1178) Arquillian Drone Module page on arquillian.org is out of date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118098#comment-13118098 ] Matous Jobanek commented on ARQ-1178: ------------------------------------- Seems to be already up to date. The Arquillian Drone WebDriver Depchain is included there as well. > Arquillian Drone Module page on arquillian.org is out of date > ------------------------------------------------------------- > > Key: ARQ-1178 > URL: https://issues.jboss.org/browse/ARQ-1178 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: drone_2.0.0.Beta1 > > > Description how to use Drone should be improved. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 14 06:45:01 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 14 Oct 2015 06:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1178) Arquillian Drone Module page on arquillian.org is out of date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek resolved ARQ-1178. --------------------------------- Resolution: Done > Arquillian Drone Module page on arquillian.org is out of date > ------------------------------------------------------------- > > Key: ARQ-1178 > URL: https://issues.jboss.org/browse/ARQ-1178 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: drone_2.0.0.Beta1 > > > Description how to use Drone should be improved. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 14 06:45:01 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 14 Oct 2015 06:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1178) Arquillian Drone Module page on arquillian.org is out of date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-1178: ----------------------------------- Assignee: Matous Jobanek (was: Karel Piwko) > Arquillian Drone Module page on arquillian.org is out of date > ------------------------------------------------------------- > > Key: ARQ-1178 > URL: https://issues.jboss.org/browse/ARQ-1178 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.0.0.Beta1 > > > Description how to use Drone should be improved. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 14 06:45:01 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 14 Oct 2015 06:45:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1340) Drone webdriver is not created during @BeforeClass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-1340: ----------------------------------- Assignee: Matous Jobanek > 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 > Assignee: Matous Jobanek > 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) From issues at jboss.org Wed Oct 14 06:45:02 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 14 Oct 2015 06:45:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1743) Merge configuration and callable creation together In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-1743: ----------------------------------- Assignee: Matous Jobanek > Merge configuration and callable creation together > -------------------------------------------------- > > Key: ARQ-1743 > URL: https://issues.jboss.org/browse/ARQ-1743 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Drone > Affects Versions: drone_2.0.0.Alpha1 > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.0.0.Beta1 > > > There should be just one event and either both or none of the object should be present. > This mean that callable and configuration should be created at the same time. This would make usage of Drone much easier. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 15:44:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 15:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1988) Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQ-1988: ------------------------------- Assignee: Aslak Knutsen > Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 > -------------------------------------------------------------- > > Key: ARQ-1988 > URL: https://issues.jboss.org/browse/ARQ-1988 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > > Warp needs to upgrade to HTTPCore 4.4.3 to be compatible with Drone 2.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:05:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-949) Warp: Improve serialization by using Externalizable instead of Serializable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-949: --------------------------- Description: What are reasons for {{Externalizable}}: * no need to define {{serialVersionUID}} What are requirements: * custom {{readObject/writeObject}} implementation in {{Inspection}} * or customized {{ObjectOutputStream}} was: What are reasons for {{Externalizable}}: * no need to define {{serialVersionUID}} What are requirements: * custom {{readObject/writeObject}} implementation in {{ServerAssertion}} * or customized {{ObjectOutputStream}} > Warp: Improve serialization by using Externalizable instead of Serializable > --------------------------------------------------------------------------- > > Key: ARQ-949 > URL: https://issues.jboss.org/browse/ARQ-949 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Reporter: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > > What are reasons for {{Externalizable}}: > * no need to define {{serialVersionUID}} > What are requirements: > * custom {{readObject/writeObject}} implementation in {{Inspection}} > * or customized {{ObjectOutputStream}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:06:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1242) Warp: test exception thrown during Proxy processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1242. ----------------------------- Fix Version/s: (was: warp_1.0.0.Beta1) Assignee: Luk?? Fry? Resolution: Deferred Deferred > Warp: test exception thrown during Proxy processing > --------------------------------------------------- > > Key: ARQ-1242 > URL: https://issues.jboss.org/browse/ARQ-1242 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > We should test what happens when Proxy fails, > and make sure the errors are handled properly. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:11:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:11:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1617) Warp: reconsider httpcore dependency of Warp impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1617. ----------------------------- Fix Version/s: (was: warp_1.0.0.Beta1) Assignee: Luk?? Fry? Resolution: Deferred > Warp: reconsider httpcore dependency of Warp impl > ------------------------------------------------- > > Key: ARQ-1617 > URL: https://issues.jboss.org/browse/ARQ-1617 > Project: Arquillian > Issue Type: Task > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > > We could either shade it > or bring own implementation - that poses quite a risk to get that right. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:16:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:16:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1272) Warp: avoid need for user-defined serialVersionUID In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1272. ----------------------------- Assignee: Luk?? Fry? Resolution: Deferred Deferred, I personally favour ARQ-949. > Warp: avoid need for user-defined serialVersionUID > -------------------------------------------------- > > Key: ARQ-1272 > URL: https://issues.jboss.org/browse/ARQ-1272 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Priority: Critical > Fix For: warp_1.0.0.Beta1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > One of the options might be to generate serialVersionUID with Lombok: > http://projectlombok.org/mavenrepo/index.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:16:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:16:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-949) Warp: Improve serialization by using Externalizable instead of Serializable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-949: --------------------------- Comment: was deleted (was: Do we still need this?) > Warp: Improve serialization by using Externalizable instead of Serializable > --------------------------------------------------------------------------- > > Key: ARQ-949 > URL: https://issues.jboss.org/browse/ARQ-949 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Reporter: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > > What are reasons for {{Externalizable}}: > * no need to define {{serialVersionUID}} > What are requirements: > * custom {{readObject/writeObject}} implementation in {{Inspection}} > * or customized {{ObjectOutputStream}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:20:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:20:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1412) Transparent failure propagation for Warp's CommandService SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1412. ----------------------------- Fix Version/s: (was: warp_1.0.0.Beta1) Assignee: Luk?? Fry? Resolution: Deferred > Transparent failure propagation for Warp's CommandService SPI > ------------------------------------------------------------- > > Key: ARQ-1412 > URL: https://issues.jboss.org/browse/ARQ-1412 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Warp > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > > When CommandService fails, it should just transport the failure. > It should be partially implemented, let's verify that with functional tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:29:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:29:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1432) Make Warp Airplane travel friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1432: ---------------------------- Issue Type: Bug (was: Enhancement) > Make Warp Airplane travel friendly > ---------------------------------- > > Key: ARQ-1432 > URL: https://issues.jboss.org/browse/ARQ-1432 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha3 > Reporter: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > Attachments: test-output.txt > > > When not connected to a network Warp throws this exception: > {code} > java.net.SocketException: Unresolved address > at java.net.DatagramSocket.connect(DatagramSocket.java:477) > at org.littleshoot.proxy.NetworkUtils.getLocalHostViaUdp(NetworkUtils.java:55) > at org.littleshoot.proxy.NetworkUtils.getLocalHost(NetworkUtils.java:46) > at org.littleshoot.proxy.ProxyUtils.(ProxyUtils.java:67) > at org.littleshoot.proxy.LittleProxyConfig.(LittleProxyConfig.java:44) > at org.jboss.arquillian.warp.impl.client.proxy.DefaultProxyService.startProxy(DefaultProxyService.java:75) > at org.jboss.arquillian.warp.impl.client.proxy.DefaultProxyService.startProxy(DefaultProxyService.java:46) > at org.jboss.arquillian.warp.impl.client.proxy.ProxyObserver.startProxy(ProxyObserver.java:71) > 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:606) > 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.warp.impl.client.proxy.ProxyObserver.requireProxy(ProxyObserver.java:66) > 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:606) > 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.warp.impl.client.proxy.ProxyURLProvider.getProxyUrl(ProxyURLProvider.java:82) > at org.jboss.arquillian.warp.impl.client.proxy.ProxyURLProvider.lookup(ProxyURLProvider.java:71) > at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:112) > at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:57) > at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52) > at org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51) > 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:606) > 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.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:606) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > 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:606) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > 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:606) > 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.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:606) > 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.before(EventTestRunnerAdaptor.java:95) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:222) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:30:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:30:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1811) Support non Warp annotations on Lifecycle methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1811: ---------------------------- Issue Type: Bug (was: Feature Request) > Support non Warp annotations on Lifecycle methods > ------------------------------------------------- > > Key: ARQ-1811 > URL: https://issues.jboss.org/browse/ARQ-1811 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > > Warp currently filter Lifecycle methods in the Inspection to only include requested qualifier annotations. > This means any other annotation driven extension cause the Lifecycle method to be ignored in-container. > https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/impl/server/test/SecurityActions.java#L219 > The code needs to only match @WarpLifecycleTest annotated annotations. > note: BeforeServlet / AfterServlet currently are not annotated with @WarpLifecycleTest -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 15 16:36:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 15 Oct 2015 16:36:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1489) Warp Filter: prepend to all other filters in a chain & do not participate in forwarding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1489: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 (was: warp_1.0.0.Alpha7) > Warp Filter: prepend to all other filters in a chain & do not participate in forwarding > --------------------------------------------------------------------------------------- > > Key: ARQ-1489 > URL: https://issues.jboss.org/browse/ARQ-1489 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Warp > Affects Versions: 1.0.0.Alpha4 > Environment: Arquillian Warp 1.0.0.Alpha4 with Rewrite 2.0.7.Final in a JBoss AS 7.1.1.Final > Reporter: Harald Albers > Assignee: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > > *Original title*: Warp: response payload was never registered when used with OCPsoft Rewrite > I use OCPsoft Rewrite (http://ocpsoft.org/rewrite/) to add fancy URL aliases to my JSF webapp. > Warp tests work as long as I use the original unaliased URLs. > Warp tests using the aliased URLs fail with > {quote} > ClientWarpExecutionException: deenriching response failed: The response payload with serialId [...] was never registered > {quote} > I created a demonstration project, see README.md for details: > https://github.com/albers/arquillian-showcase/tree/rewrite -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:20:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:20:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-483: ------------------------------ Fix Version/s: 2.1-Tracking > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > Fix For: 2.1-Tracking > > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L54 > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:23:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:23:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-482) Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-482. ------------------------------- Assignee: Matous Jobanek Resolution: Done > Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called > ----------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-482 > URL: https://issues.jboss.org/browse/ARQGRA-482 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 2.1-Tracking > > > When takeOnEveryAction is activated and either {{WebDriver.close()}} or {{WebDriver.quit()}} is called, then this exception is thrown: > {noformat} > java.lang.RuntimeException: Error during saving the screenshot! > at org.arquillian.extension.recorder.screenshooter.browser.impl.BrowserScreenshooter.takeScreenshot(BrowserScreenshooter.java:126) > at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotAndReportService.takeScreenshotAndReport(TakeScreenshotAndReportService.java:60) > at org.arquillian.extension.recorder.screenshooter.browser.impl.AbstractTakeScreenshotInterceptor.takeScreenshotAndReport(AbstractTakeScreenshotInterceptor.java:46) > at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotOnEveryActionInterceptor.intercept(TakeScreenshotOnEveryActionInterceptor.java:75) > at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) > at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) > at org.openqa.selenium.phantomjs.PhantomJSDriver$$EnhancerByGraphene$$8a745fde.close() > at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase$OnEveryActionManyActionsTestClass.testMethod(OnEveryActionScreenshotTestCase.java:135) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at org.junit.runner.JUnitCore.run(JUnitCore.java:128) > at org.junit.runner.JUnitCore.runClasses(JUnitCore.java:73) > at org.jboss.arquillian.graphene.screenshooter.ftest.when.AbstractScreenshotTestCase.runTest(AbstractScreenshotTestCase.java:53) > at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase.onEveryActionManyActionsTest(OnEveryActionScreenshotTestCase.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > 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 org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.openqa.selenium.NoSuchWindowException: {"errorMessage":"Currently Window handle/name is invalid (closed?)","request":{"headers":{"Accept-Encoding":"gzip,deflate","Cache-Control":"no-cache","Connection":"Keep-Alive","Host":"localhost:8148","User-Agent":"Apache-HttpClient/4.4.1 (Java/1.8.0_05)"},"httpVersion":"1.1","method":"GET","url":"/screenshot","urlParsed":{"anchor":"","query":"","file":"screenshot","directory":"/","path":"/screenshot","relative":"/screenshot","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/screenshot","queryKey":{},"chunks":["screenshot"]},"urlOriginal":"/session/a57ad390-6c28-11e5-b917-2bceae0d5451/screenshot"}} > Command duration or timeout: 48 milliseconds > {noformat} > This behaviour is expected, because there nothing where the screenshot could be taken. Solution is to remove these two methods from the allowed list. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:23:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:23:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQGRA-480. ------------------------------- Assignee: Matous Jobanek Resolution: Done > Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-480 > URL: https://issues.jboss.org/browse/ARQGRA-480 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 2.1-Tracking > > > Consider this scenario: > Arquillian.xml contains: > {code:xml} > > true > false > false > false > > {code} > Then, when the test starts this output is written there in the console log: > {noformat} > Configuration of Arquillian Browser Screenshooter: > rootDir target/screenshots > screenshotType PNG > takeBeforeTest true > takeAfterTest false > takeWhenTestFailed false > takeOnEveryAction true > {noformat} > There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. > The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: > 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase > 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:27:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:27:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-481: ------------------------------ Fix Version/s: 2.0-Tracking > generic attribute injection doesn't work > ---------------------------------------- > > Key: ARQGRA-481 > URL: https://issues.jboss.org/browse/ARQGRA-481 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final > Environment: OS: Win7 > Java: 1.7.0_17 > AS: Wildfly 8.2.0.final > Reporter: Robert Hoeppner > Fix For: 2.0-Tracking > > Attachments: stacktrace.txt > > > I have an abstract PageObject like these: > {code:java} > public abstract class AbstractBenutzerdatenPageWithEdit extends > AbstractBenutzerdatenPage { > @FindBy(id = "browser:editDialog:dlg_container") > private EDITDLG editDialog; > public EDITDLG getEditDialog() { > return editDialog; > } > } > {code} > AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: > {code:java} > @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") > public class FristenPage extends AbstractBenutzerdatenPageWithEdit { > ..... > } > {code} > at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment > {code:java} > public class FristenEditDialogFragment extends AbstractEditDialogFragment { > ... > } > {code} > The test looking like these: > {code:java} > @RunWith(Arquillian.class) > @RunAsClient > public class FristenTest extends TestDeployments { > @ArquillianResource > private URL contextPath; > @Drone > private WebDriver driver; > @Page > private LoginPage loginPage; > @Page > private HomePage homePage; > @Page > private BenutzerdatenHomePage benutzerdatenHomePage; > @Page > private FristenPage fristenPage; > @Test > public void PageAccessTest(@InitialPage LoginPage loginP) { > loginP.loginWithCredentials("admin", "gip123"); > homePage.getNavigationBar().navigateToUserData(); > benutzerdatenHomePage.getMenu().openFristen(); > assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); > } > {code} > And if i run this test, i get a PageObjectInitializationException > {code} > org.jboss.arquillian.graphene.enricher.exception.PageObjectInitializationException: Can not instantiate Page Object > class de.gipmbh.absenz.web.pageModel.benutzerdaten.FristenPage > declared in: > de.gipmbh.absenz.web.uitests.benutzerdaten.FristenTest > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:28:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:28:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118973#comment-13118973 ] Luk?? Fry? commented on ARQGRA-481: ----------------------------------- Hi [~hoeppnerrobert], any chance you could get this reproduced in Graphene's functional test suite? https://github.com/arquillian/arquillian-graphene/tree/master/ftest/src/test/java/org/jboss/arquillian/graphene/ftest/enricher > generic attribute injection doesn't work > ---------------------------------------- > > Key: ARQGRA-481 > URL: https://issues.jboss.org/browse/ARQGRA-481 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final > Environment: OS: Win7 > Java: 1.7.0_17 > AS: Wildfly 8.2.0.final > Reporter: Robert Hoeppner > Fix For: 2.0-Tracking > > Attachments: stacktrace.txt > > > I have an abstract PageObject like these: > {code:java} > public abstract class AbstractBenutzerdatenPageWithEdit extends > AbstractBenutzerdatenPage { > @FindBy(id = "browser:editDialog:dlg_container") > private EDITDLG editDialog; > public EDITDLG getEditDialog() { > return editDialog; > } > } > {code} > AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: > {code:java} > @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") > public class FristenPage extends AbstractBenutzerdatenPageWithEdit { > ..... > } > {code} > at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment > {code:java} > public class FristenEditDialogFragment extends AbstractEditDialogFragment { > ... > } > {code} > The test looking like these: > {code:java} > @RunWith(Arquillian.class) > @RunAsClient > public class FristenTest extends TestDeployments { > @ArquillianResource > private URL contextPath; > @Drone > private WebDriver driver; > @Page > private LoginPage loginPage; > @Page > private HomePage homePage; > @Page > private BenutzerdatenHomePage benutzerdatenHomePage; > @Page > private FristenPage fristenPage; > @Test > public void PageAccessTest(@InitialPage LoginPage loginP) { > loginP.loginWithCredentials("admin", "gip123"); > homePage.getNavigationBar().navigateToUserData(); > benutzerdatenHomePage.getMenu().openFristen(); > assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); > } > {code} > And if i run this test, i get a PageObjectInitializationException > {code} > org.jboss.arquillian.graphene.enricher.exception.PageObjectInitializationException: Can not instantiate Page Object > class de.gipmbh.absenz.web.pageModel.benutzerdaten.FristenPage > declared in: > de.gipmbh.absenz.web.uitests.benutzerdaten.FristenTest > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:29:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:29:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-477) Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-477: ------------------------------ Fix Version/s: 2.1-Tracking > Upgrade to Core 1.1.8, Drone 2.0.0.Alpha5, Selenium 2.47.1 > ----------------------------------------------------------- > > Key: ARQGRA-477 > URL: https://issues.jboss.org/browse/ARQGRA-477 > Project: Arquillian Graphene > Issue Type: Component Upgrade > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:32:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:32:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-476) Extend root element from GrapheneElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-476: ------------------------------ Fix Version/s: 2.1-Tracking > Extend root element from GrapheneElement > ----------------------------------------- > > Key: ARQGRA-476 > URL: https://issues.jboss.org/browse/ARQGRA-476 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Priority: Minor > Fix For: 2.1-Tracking > > > Currently the root element in page fragments must extend WebElement. I would like to extend this, so it can also extend GrapheneElement. I'm preparing a pull request for this currently. Would be nice if this enhancement would make it to the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:32:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:32:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-475) Support inheritance for page fragments delegating to WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-475: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Support inheritance for page fragments delegating to WebElement > --------------------------------------------------------------- > > Key: ARQGRA-475 > URL: https://issues.jboss.org/browse/ARQGRA-475 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Priority: Minor > > When implementing page fragments that extend WebElement as described in https://docs.jboss.org/author/display/ARQGRA2/Delegate+to+WebElement it is not possible to use superclasses for this construct. > This is because the method {{isAboutToDelegateToWebElement}} in {{PageFragmentEnricher}} just searches the current class, but not the superclasses. > I'm preparing a minor change for this currently. Hope to send the pull request soon. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:32:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:32:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-476) Extend root element from GrapheneElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-476: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Extend root element from GrapheneElement > ----------------------------------------- > > Key: ARQGRA-476 > URL: https://issues.jboss.org/browse/ARQGRA-476 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Priority: Minor > Fix For: 2.1-Tracking > > > Currently the root element in page fragments must extend WebElement. I would like to extend this, so it can also extend GrapheneElement. I'm preparing a pull request for this currently. Would be nice if this enhancement would make it to the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:33:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:33:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-474) Remove arquillian-graphene depchain as no one uses it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-474: ------------------------------ Summary: Remove arquillian-graphene depchain as no one uses it (was: Remove arquillian-graphene as no one uses it) > Remove arquillian-graphene depchain as no one uses it > ----------------------------------------------------- > > Key: ARQGRA-474 > URL: https://issues.jboss.org/browse/ARQGRA-474 > Project: Arquillian Graphene > Issue Type: Task > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > > Docs and tutorials mention graphene-webdriver depchain: > https://docs.jboss.org/author/display/ARQGRA2/Framework+Integration+Options > http://arquillian.org/guides/functional_testing_using_graphene/ > The depchains are not used by EAP BOMs too: > https://issues.jboss.org/browse/JDF-840 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:34:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-474) Remove arquillian-graphene depchain as no one uses it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-474: ------------------------------ Status: Open (was: Pull Request Sent) This is confusing, the issue says there is a PR sent but I can't see any. We still need to remove it. > Remove arquillian-graphene depchain as no one uses it > ----------------------------------------------------- > > Key: ARQGRA-474 > URL: https://issues.jboss.org/browse/ARQGRA-474 > Project: Arquillian Graphene > Issue Type: Task > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > > Docs and tutorials mention graphene-webdriver depchain: > https://docs.jboss.org/author/display/ARQGRA2/Framework+Integration+Options > http://arquillian.org/guides/functional_testing_using_graphene/ > The depchains are not used by EAP BOMs too: > https://issues.jboss.org/browse/JDF-840 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:36:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:36:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-472) TestCases are copy-pasted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-472: ------------------------------ Fix Version/s: 2.1-Tracking > TestCases are copy-pasted > ------------------------- > > Key: ARQGRA-472 > URL: https://issues.jboss.org/browse/ARQGRA-472 > Project: Arquillian Graphene > Issue Type: Bug > Components: unit-test > Affects Versions: 2.1-Tracking > Reporter: Vitalii Grygoryuk > Fix For: 2.1-Tracking > > > TestHandlingOfStaleElements.testDeletion() and TestHandlingOfStaleElements.testReplacement() are both testing deletion, so there is no test case for node replacement logic: > {code} > @Test > public void testDeletion() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > @Test > public void testReplacement() { > rootElement.isDisplayed(); > executor.executeScript("return arguments[0].parentNode.removeChild(arguments[0])", rootElement); > try { > rootElement.isDisplayed(); > fail("rootElement should not be found"); > } catch (NoSuchElementException e) { > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:37:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-471) GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-471: ------------------------------ Fix Version/s: 2.1-Tracking > GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException > ------------------------------------------------------------------------------- > > Key: ARQGRA-471 > URL: https://issues.jboss.org/browse/ARQGRA-471 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.1.0.Alpha2 > Reporter: Ji?? ?tefek > Priority: Trivial > Fix For: 2.1-Tracking > > > When you perform an assertion in e.g. a page fragment, which leads to throwing an AssertionError, the error is wrapped in IllegalStateException. This is imho an unwanted behaviour and these errors should be forwarded. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:37:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-471) GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118977#comment-13118977 ] Luk?? Fry? commented on ARQGRA-471: ----------------------------------- [~jstefek] do you have any concrete sample? > GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException > ------------------------------------------------------------------------------- > > Key: ARQGRA-471 > URL: https://issues.jboss.org/browse/ARQGRA-471 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.1.0.Alpha2 > Reporter: Ji?? ?tefek > Priority: Trivial > Fix For: 2.1-Tracking > > > When you perform an assertion in e.g. a page fragment, which leads to throwing an AssertionError, the error is wrapped in IllegalStateException. This is imho an unwanted behaviour and these errors should be forwarded. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 05:38:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 16 Oct 2015 05:38:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-326) Support for full initialization of outer class instance of a page fragment declared as inner class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-326: ------------------------------ Fix Version/s: 2.1-Tracking (was: 2.0-Tracking) > Support for full initialization of outer class instance of a page fragment declared as inner class > -------------------------------------------------------------------------------------------------- > > Key: ARQGRA-326 > URL: https://issues.jboss.org/browse/ARQGRA-326 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.0.Alpha4 > Reporter: Juraj H?ska > Priority: Minor > Fix For: 2.1-Tracking > > > If a Page Fragment is declared as inner class, then it can not access the fields of its outer class, as their are not inicialized by Graphene Enrichers, thus are {{null}}. > The possible ugly workaround for such initialization can be: > {code} > if (pageFragment.getClass().getEnclosingClass() != null) { > Field field = pageFragment.getClass().getDeclaredField("this$0"); > field.setAccessible(true); > Object outer = field.get(pageFragment); > enrichRecursively(root, outer); > } > {code} > It should be placed in some utility class, so it can be easily unit tested. > There is one drawback of this method and that is, the outer class can not contain injection point for the inner class, otherwise it will cycle. The inner class can be obtained only dynamically via {{Graphene.createPageFragment}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 06:11:00 2015 From: issues at jboss.org (Andreas Weise (JIRA)) Date: Fri, 16 Oct 2015 06:11:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118989#comment-13118989 ] Andreas Weise commented on ARQ-1992: ------------------------------------ Direct linnk to reproducer is https://github.com/catandgrep/wildfly-undertow-mem-leak > 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) From issues at jboss.org Fri Oct 16 06:28:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 16 Oct 2015 06:28:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118996#comment-13118996 ] Aslak Knutsen commented on ARQ-1992: ------------------------------------ Aa, nice catch. I guess a local reference would do just as well. > 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) From issues at jboss.org Fri Oct 16 07:03:00 2015 From: issues at jboss.org (Robert Hoeppner (JIRA)) Date: Fri, 16 Oct 2015 07:03:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-481) generic attribute injection doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119010#comment-13119010 ] Robert Hoeppner commented on ARQGRA-481: ---------------------------------------- Yes, i will create a test case. But please give me some time for this > generic attribute injection doesn't work > ---------------------------------------- > > Key: ARQGRA-481 > URL: https://issues.jboss.org/browse/ARQGRA-481 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final > Environment: OS: Win7 > Java: 1.7.0_17 > AS: Wildfly 8.2.0.final > Reporter: Robert Hoeppner > Fix For: 2.0-Tracking > > Attachments: stacktrace.txt > > > I have an abstract PageObject like these: > {code:java} > public abstract class AbstractBenutzerdatenPageWithEdit extends > AbstractBenutzerdatenPage { > @FindBy(id = "browser:editDialog:dlg_container") > private EDITDLG editDialog; > public EDITDLG getEditDialog() { > return editDialog; > } > } > {code} > AbstractEditDialogFragment has three concrete implementations and there are three implementations of AbstractBenutzerdatenPageWithEdit like the following: > {code:java} > @Location("pages/benutzerdaten/fehlzeit/frist.xhtml") > public class FristenPage extends AbstractBenutzerdatenPageWithEdit { > ..... > } > {code} > at which FristenEditDialogFragment is one concrete implementation of AbstractEditDialogFragment > {code:java} > public class FristenEditDialogFragment extends AbstractEditDialogFragment { > ... > } > {code} > The test looking like these: > {code:java} > @RunWith(Arquillian.class) > @RunAsClient > public class FristenTest extends TestDeployments { > @ArquillianResource > private URL contextPath; > @Drone > private WebDriver driver; > @Page > private LoginPage loginPage; > @Page > private HomePage homePage; > @Page > private BenutzerdatenHomePage benutzerdatenHomePage; > @Page > private FristenPage fristenPage; > @Test > public void PageAccessTest(@InitialPage LoginPage loginP) { > loginP.loginWithCredentials("admin", "gip123"); > homePage.getNavigationBar().navigateToUserData(); > benutzerdatenHomePage.getMenu().openFristen(); > assertThat(fristenPage.getBreadCrumbText()).isEqualTo("? Benutzerdaten ?Fehlzeiten ? Fristen"); > } > {code} > And if i run this test, i get a PageObjectInitializationException > {code} > org.jboss.arquillian.graphene.enricher.exception.PageObjectInitializationException: Can not instantiate Page Object > class de.gipmbh.absenz.web.pageModel.benutzerdaten.FristenPage > declared in: > de.gipmbh.absenz.web.uitests.benutzerdaten.FristenTest > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 08:09:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 16 Oct 2015 08:09:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1993) Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-1993: ----------------------------------- Summary: Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. Key: ARQ-1993 URL: https://issues.jboss.org/browse/ARQ-1993 Project: Arquillian Issue Type: Bug Components: Extension - Recorder Affects Versions: recorder_1.1.0.Alpha3 Reporter: Matous Jobanek Both the [TestInstanceEnricher|https://github.com/arquillian/arquillian-core/blob/master/test/impl-base/src/main/java/org/jboss/arquillian/test/impl/TestInstanceEnricher.java#L46] (DroneTestEnricher) and [ScreenshooterLifecycleObserver|https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L69] has the very same precedence = 0, so it is just question of luck what is called first. When the ScreenshooterLifecycleObserver is called before the DroneTestEnricher then no instance of Drone is available and [this exception|https://gist.github.com/lfryc/436a4ac99560f7ddf394] is thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 08:15:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 16 Oct 2015 08:15:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1993) Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1993: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-recorder/pull/21 > Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. > ---------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1993 > URL: https://issues.jboss.org/browse/ARQ-1993 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Matous Jobanek > > Both the [TestInstanceEnricher|https://github.com/arquillian/arquillian-core/blob/master/test/impl-base/src/main/java/org/jboss/arquillian/test/impl/TestInstanceEnricher.java#L46] (DroneTestEnricher) and [ScreenshooterLifecycleObserver|https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L69] has the very same precedence = 0, so it is just question of luck what is called first. When the ScreenshooterLifecycleObserver is called before the DroneTestEnricher then no instance of Drone is available and [this exception|https://gist.github.com/lfryc/436a4ac99560f7ddf394] is thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 08:15:01 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 16 Oct 2015 08:15:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1993) Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-1993: ----------------------------------- Assignee: Matous Jobanek > Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. > ---------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1993 > URL: https://issues.jboss.org/browse/ARQ-1993 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > > Both the [TestInstanceEnricher|https://github.com/arquillian/arquillian-core/blob/master/test/impl-base/src/main/java/org/jboss/arquillian/test/impl/TestInstanceEnricher.java#L46] (DroneTestEnricher) and [ScreenshooterLifecycleObserver|https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L69] has the very same precedence = 0, so it is just question of luck what is called first. When the ScreenshooterLifecycleObserver is called before the DroneTestEnricher then no instance of Drone is available and [this exception|https://gist.github.com/lfryc/436a4ac99560f7ddf394] is thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 08:49:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 16 Oct 2015 08:49:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1993) Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1993: -------------------------------- Fix Version/s: recorder_1.1.0.Alpha4 > Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. > ---------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1993 > URL: https://issues.jboss.org/browse/ARQ-1993 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: recorder_1.1.0.Alpha4 > > > Both the [TestInstanceEnricher|https://github.com/arquillian/arquillian-core/blob/master/test/impl-base/src/main/java/org/jboss/arquillian/test/impl/TestInstanceEnricher.java#L46] (DroneTestEnricher) and [ScreenshooterLifecycleObserver|https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L69] has the very same precedence = 0, so it is just question of luck what is called first. When the ScreenshooterLifecycleObserver is called before the DroneTestEnricher then no instance of Drone is available and [this exception|https://gist.github.com/lfryc/436a4ac99560f7ddf394] is thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 11:09:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 16 Oct 2015 11:09:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1992: ------------------------------- Fix Version/s: 1.2.0.Alpha1 > 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 > Fix For: 1.2.0.Alpha1 > > > 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) From issues at jboss.org Fri Oct 16 11:10:01 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 16 Oct 2015 11:10:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1992: ------------------------------- Fix Version/s: 1.1.10.Final (was: 1.2.0.Alpha1) > 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 > Fix For: 1.1.10.Final > > > 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) From issues at jboss.org Fri Oct 16 11:13:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 16 Oct 2015 11:13:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1692) Factories should not bring runtime dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1692: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/54 > Factories should not bring runtime dependencies > ----------------------------------------------- > > Key: ARQ-1692 > URL: https://issues.jboss.org/browse/ARQ-1692 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Fix For: drone_2.0.0.Beta1 > > > DroneFactories should fail graciously in case that Drone type they are trying to instantiate are not on classpath. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 11:13:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 16 Oct 2015 11:13:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1992. -------------------------------- Resolution: Partially Completed Pushed upstream https://github.com/arquillian/arquillian-core/commit/0c69a4fcc9b24e0712b8342784efb93dddf9c6fb > 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 > Fix For: 1.1.10.Final > > > 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) From issues at jboss.org Fri Oct 16 11:13:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Fri, 16 Oct 2015 11:13:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1692) Factories should not bring runtime dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-1692: ----------------------------------- Assignee: Matous Jobanek > Factories should not bring runtime dependencies > ----------------------------------------------- > > Key: ARQ-1692 > URL: https://issues.jboss.org/browse/ARQ-1692 > Project: Arquillian > Issue Type: Task > Components: Extension - Drone > Reporter: Karel Piwko > Assignee: Matous Jobanek > Fix For: drone_2.0.0.Beta1 > > > DroneFactories should fail graciously in case that Drone type they are trying to instantiate are not on classpath. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 11:13:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 16 Oct 2015 11:13:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1985) Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1985: ------------------------------- Fix Version/s: 1.1.10.Final (was: 1.2.0.Alpha1) > Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 > -------------------------------------------------------- > > Key: ARQ-1985 > URL: https://issues.jboss.org/browse/ARQ-1985 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.9.Final > Reporter: Aslak Knutsen > Fix For: 1.1.10.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 16 11:14:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 16 Oct 2015 11:14:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1984) Update version of ShrinkWrap Resolver to 2.2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1984: ------------------------------- Fix Version/s: 1.1.10.Final (was: 1.2.0.Alpha1) > Update version of ShrinkWrap Resolver to 2.2.0 > ---------------------------------------------- > > Key: ARQ-1984 > URL: https://issues.jboss.org/browse/ARQ-1984 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.9.Final > Reporter: Matous Jobanek > Fix For: 1.1.10.Final > > > Update version of ShrinkWrap Resolver to 2.2.0 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 03:42:00 2015 From: issues at jboss.org (=?UTF-8?Q?Ji=C5=99=C3=AD_=C5=A0tefek_=28JIRA=29?=) Date: Mon, 19 Oct 2015 03:42:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-471) GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119289#comment-13119289 ] Ji?? ?tefek commented on ARQGRA-471: ------------------------------------ [~lfryc], you can use: https://github.com/jstefek/arquillian-graphene/commit/bb1a2e1de88672bcd6dbfe76eac98ed65b89b23b > GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException > ------------------------------------------------------------------------------- > > Key: ARQGRA-471 > URL: https://issues.jboss.org/browse/ARQGRA-471 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.1.0.Alpha2 > Reporter: Ji?? ?tefek > Priority: Trivial > Fix For: 2.1-Tracking > > > When you perform an assertion in e.g. a page fragment, which leads to throwing an AssertionError, the error is wrapped in IllegalStateException. This is imho an unwanted behaviour and these errors should be forwarded. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 04:34:00 2015 From: issues at jboss.org (pueffl (JIRA)) Date: Mon, 19 Oct 2015 04:34:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1994) Wrong root path in Testcase In-Reply-To: References: Message-ID: pueffl created ARQ-1994: --------------------------- Summary: Wrong root path in Testcase Key: ARQ-1994 URL: https://issues.jboss.org/browse/ARQ-1994 Project: Arquillian Issue Type: Bug Affects Versions: 1.1.9.Final, 1.1.8.Final Reporter: pueffl After deploying a .war to JBoss Wildfly, I start a Testcase and want to read a XML-File from the filesystem (relative path -> /target/test-classes). As this didn't work, I checked the path: System.out.println(new File("test.txt").getAbsolutePath()); The result was References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119345#comment-13119345 ] Aslak Knutsen commented on ARQ-1994: ------------------------------------ This is not a bug. This is the effect of in-container testing. If you run in-container the test code is executed inside the server not inside your 'IDE'. You have 2 options; 1. You really wanted to run the test on the client side and only reach the deployment via external exported endpoints, e.g. http, then you can use @Deployment.testable=false. 2. Or you want to test in-container but require resources only available on the client side. Then add those resources to the Deployment and load them via the Classloader, not file system. > Wrong root path in Testcase > --------------------------- > > Key: ARQ-1994 > URL: https://issues.jboss.org/browse/ARQ-1994 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.8.Final, 1.1.9.Final > Reporter: pueffl > > After deploying a .war to JBoss Wildfly, I start a Testcase and want to read a XML-File from the filesystem (relative path -> /target/test-classes). As this didn't work, I checked the path: System.out.println(new File("test.txt").getAbsolutePath()); > The result was I am not absolutely sure if this is a bug, but it hampers testing a lot in some cases and it should at least be better documented. (I couldn't find information about this behavior so far.) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 06:17:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 06:17:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1993) Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek resolved ARQ-1993. --------------------------------- Resolution: Done > Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. > ---------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1993 > URL: https://issues.jboss.org/browse/ARQ-1993 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: recorder_1.1.0.Alpha4 > > > Both the [TestInstanceEnricher|https://github.com/arquillian/arquillian-core/blob/master/test/impl-base/src/main/java/org/jboss/arquillian/test/impl/TestInstanceEnricher.java#L46] (DroneTestEnricher) and [ScreenshooterLifecycleObserver|https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L69] has the very same precedence = 0, so it is just question of luck what is called first. When the ScreenshooterLifecycleObserver is called before the DroneTestEnricher then no instance of Drone is available and [this exception|https://gist.github.com/lfryc/436a4ac99560f7ddf394] is thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 06:17:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 06:17:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1993) Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-1993. ------------------------------- > Occasional ISE - There is no context available for qualifier org.jboss.arquillian.drone.api.annotation.Default. > ---------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1993 > URL: https://issues.jboss.org/browse/ARQ-1993 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: recorder_1.1.0.Alpha4 > > > Both the [TestInstanceEnricher|https://github.com/arquillian/arquillian-core/blob/master/test/impl-base/src/main/java/org/jboss/arquillian/test/impl/TestInstanceEnricher.java#L46] (DroneTestEnricher) and [ScreenshooterLifecycleObserver|https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-screenshooter-base/arquillian-recorder-screenshooter-impl-base/src/main/java/org/arquillian/extension/recorder/screenshooter/impl/ScreenshooterLifecycleObserver.java#L69] has the very same precedence = 0, so it is just question of luck what is called first. When the ScreenshooterLifecycleObserver is called before the DroneTestEnricher then no instance of Drone is available and [this exception|https://gist.github.com/lfryc/436a4ac99560f7ddf394] is thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 06:18:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 06:18:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1989) Video-impl-base fail if no impl is on classpath In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1989: -------------------------------- Fix Version/s: (was: recorder_1.1.0.Alpha4) > Video-impl-base fail if no impl is on classpath > ----------------------------------------------- > > Key: ARQ-1989 > URL: https://issues.jboss.org/browse/ARQ-1989 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Aslak Knutsen > > {code} > java.lang.NullPointerException > at org.arquillian.extension.recorder.video.impl.VideoLifecycleObserver.beforeSuite(VideoLifecycleObserver.java:93) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > {code} > With no Video Recorder Implementation on classpath the Video Impl fail. Even tho it has a DefaultVideoStrategy it can use, the registration of this service rely on the VideoExtensionConfigured event which is never fired if no Video impl is found on classpath. Attempting to read that strategy then fails with a NPE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 06:19:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 06:19:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1990) Should not export tests classified dependencies in compile scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-1990. ------------------------------- > Should not export tests classified dependencies in compile scope > ---------------------------------------------------------------- > > Key: ARQ-1990 > URL: https://issues.jboss.org/browse/ARQ-1990 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: recorder_1.1.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 08:44:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 08:44:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1989) Video-impl-base fail if no impl is on classpath In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1989: -------------------------------- Fix Version/s: recorder_1.1.0.Alpha5 > Video-impl-base fail if no impl is on classpath > ----------------------------------------------- > > Key: ARQ-1989 > URL: https://issues.jboss.org/browse/ARQ-1989 > Project: Arquillian > Issue Type: Enhancement > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Aslak Knutsen > Fix For: recorder_1.1.0.Alpha5 > > > {code} > java.lang.NullPointerException > at org.arquillian.extension.recorder.video.impl.VideoLifecycleObserver.beforeSuite(VideoLifecycleObserver.java:93) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > {code} > With no Video Recorder Implementation on classpath the Video Impl fail. Even tho it has a DefaultVideoStrategy it can use, the registration of this service rely on the VideoExtensionConfigured event which is never fired if no Video impl is found on classpath. Attempting to read that strategy then fails with a NPE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:02:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 19 Oct 2015 09:02:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1994) Wrong root path in Testcase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1994. ------------------------------ Assignee: Aslak Knutsen Resolution: Rejected > Wrong root path in Testcase > --------------------------- > > Key: ARQ-1994 > URL: https://issues.jboss.org/browse/ARQ-1994 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.8.Final, 1.1.9.Final > Reporter: pueffl > Assignee: Aslak Knutsen > > After deploying a .war to JBoss Wildfly, I start a Testcase and want to read a XML-File from the filesystem (relative path -> /target/test-classes). As this didn't work, I checked the path: System.out.println(new File("test.txt").getAbsolutePath()); > The result was I am not absolutely sure if this is a bug, but it hampers testing a lot in some cases and it should at least be better documented. (I couldn't find information about this behavior so far.) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:06:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 19 Oct 2015 09:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1992) ServletTestRunner is leaking memmory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1992. ------------------------------ > 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 > Fix For: 1.1.10.Final > > > 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) From issues at jboss.org Mon Oct 19 09:06:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 19 Oct 2015 09:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1985) Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1985. ------------------------------ > Update version of ShrinkWrap Descriptor to 2.0.0-alpha-8 > -------------------------------------------------------- > > Key: ARQ-1985 > URL: https://issues.jboss.org/browse/ARQ-1985 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.9.Final > Reporter: Aslak Knutsen > Fix For: 1.1.10.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:06:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 19 Oct 2015 09:06:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1984) Update version of ShrinkWrap Resolver to 2.2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1984. ------------------------------ > Update version of ShrinkWrap Resolver to 2.2.0 > ---------------------------------------------- > > Key: ARQ-1984 > URL: https://issues.jboss.org/browse/ARQ-1984 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.9.Final > Reporter: Matous Jobanek > Fix For: 1.1.10.Final > > > Update version of ShrinkWrap Resolver to 2.2.0 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:19:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 09:19:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1995) Update to latest version of Selenium and Arquillian core In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-1995: ----------------------------------- Summary: Update to latest version of Selenium and Arquillian core Key: ARQ-1995 URL: https://issues.jboss.org/browse/ARQ-1995 Project: Arquillian Issue Type: Component Upgrade Components: Extension - Drone Reporter: Matous Jobanek Assignee: Matous Jobanek Fix For: 2.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:21:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 09:21:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1995) Update to latest version of Selenium and Arquillian core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-1995: -------------------------------- Fix Version/s: drone_2.0.0.Beta1 (was: 2.0.0.Beta1) > Update to latest version of Selenium and Arquillian core > -------------------------------------------------------- > > Key: ARQ-1995 > URL: https://issues.jboss.org/browse/ARQ-1995 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:24:00 2015 From: issues at jboss.org (pueffl (JIRA)) Date: Mon, 19 Oct 2015 09:24:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1994) Wrong root path in Testcase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119452#comment-13119452 ] pueffl commented on ARQ-1994: ----------------------------- Thanks Aslak. I tried this before but it didn't work because I did something wrong. I added the files with addAsResouce(...) and get it with getClass().getResourceAsStream("/...") and everything works fine. > Wrong root path in Testcase > --------------------------- > > Key: ARQ-1994 > URL: https://issues.jboss.org/browse/ARQ-1994 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.8.Final, 1.1.9.Final > Reporter: pueffl > Assignee: Aslak Knutsen > > After deploying a .war to JBoss Wildfly, I start a Testcase and want to read a XML-File from the filesystem (relative path -> /target/test-classes). As this didn't work, I checked the path: System.out.println(new File("test.txt").getAbsolutePath()); > The result was I am not absolutely sure if this is a bug, but it hampers testing a lot in some cases and it should at least be better documented. (I couldn't find information about this behavior so far.) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:28:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 09:28:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1995) Update to latest version of Selenium and Arquillian core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119457#comment-13119457 ] Matous Jobanek commented on ARQ-1995: ------------------------------------- ARQ-1995 Updated to Selenium 2.48.2 and Arquillian core 1.1.9.Final https://github.com/arquillian/arquillian-extension-drone/pull/55 > Update to latest version of Selenium and Arquillian core > -------------------------------------------------------- > > Key: ARQ-1995 > URL: https://issues.jboss.org/browse/ARQ-1995 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 09:37:00 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Oct 2015 09:37:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1995) Update to latest version of Selenium and Arquillian core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119457#comment-13119457 ] Matous Jobanek edited comment on ARQ-1995 at 10/19/15 9:36 AM: --------------------------------------------------------------- ARQ-1995 Updated to Selenium 2.48.2 and Arquillian core 1.1.10.Final https://github.com/arquillian/arquillian-extension-drone/pull/55 was (Author: mjobanek): ARQ-1995 Updated to Selenium 2.48.2 and Arquillian core 1.1.9.Final https://github.com/arquillian/arquillian-extension-drone/pull/55 > Update to latest version of Selenium and Arquillian core > -------------------------------------------------------- > > Key: ARQ-1995 > URL: https://issues.jboss.org/browse/ARQ-1995 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Drone > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 19 13:52:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 19 Oct 2015 13:52:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-471) GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119588#comment-13119588 ] Luk?? Fry? commented on ARQGRA-471: ----------------------------------- Nice, thanks Jiri! > GrapheneContextualHandler: do not wrap AssertionErrors in IllegalStateException > ------------------------------------------------------------------------------- > > Key: ARQGRA-471 > URL: https://issues.jboss.org/browse/ARQGRA-471 > Project: Arquillian Graphene > Issue Type: Enhancement > Affects Versions: 2.1.0.Alpha2 > Reporter: Ji?? ?tefek > Priority: Trivial > Fix For: 2.1-Tracking > > > When you perform an assertion in e.g. a page fragment, which leads to throwing an AssertionError, the error is wrapped in IllegalStateException. This is imho an unwanted behaviour and these errors should be forwarded. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:00:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:00:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-86: -------------------------------- Assignee: Luk?? Fry? (was: Juraj H?ska) > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:00:00 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:00:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQGRA-86 stopped by Luk?? Fry?. ---------------------------------------- > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:00:01 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:00:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-86: -------------------------------- Assignee: (was: Luk?? Fry?) > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Reporter: Luk?? Fry? > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:01 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-479) Propagate xhr.response values in wrapper callback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-479: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.0-Tracking) (was: 2.1-Tracking) > Propagate xhr.response values in wrapper callback > ------------------------------------------------- > > Key: ARQGRA-479 > URL: https://issues.jboss.org/browse/ARQGRA-479 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: 2.1.0.Alpha3 > > > When the xhr wrapper is created the response property is copied but it isn't updated in the callback, which leads to the property values' being out of sync. Some frameworks (e.g. Angular) will use the xhr.response over xhr.responseText if it is present, which means that simply using a guardAjax in a Graphene test will cause all subsequent xhr calls to return invalid data. In my case (Firefox 38, Angular 1.4.4, Graphene 2.0.3.Final) all $http calls would return "" once a guardAjax was executed, despite valid data being shown in Firefox's request log. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:01 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-470) Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-470: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.1-Tracking) > Missing version of org.jboss.logging:jboss-logging in org.jboss.arquillian.graphene:graphene-parent > --------------------------------------------------------------------------------------------------- > > Key: ARQGRA-470 > URL: https://issues.jboss.org/browse/ARQGRA-470 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 2.1.0.Alpha3 > > > There in the org.jboss.arquillian.graphene:graphene-parent pom is defined a dependency: > {code:xml} > > org.jboss.logging > jboss-logging > ${version.jboss.logging} > > {code} > however the variable {{version.jboss.logging}} is not defined neither it this pom nor in the parent pom. > see: > [org.jboss.arquillian.graphene:graphene-parent:2.1.0.Alpha2|https://repo1.maven.org/maven2/org/jboss/arquillian/graphene/graphene-parent/2.1.0.Alpha2/graphene-parent-2.1.0.Alpha2.pom] > [github|https://github.com/arquillian/arquillian-graphene/blob/master/pom.xml] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:01 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-478) Add support for multiple @InitialPage when using Qualifiers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-478: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.1-Tracking) > Add support for multiple @InitialPage when using Qualifiers > ----------------------------------------------------------- > > Key: ARQGRA-478 > URL: https://issues.jboss.org/browse/ARQGRA-478 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Reporter: Michael Irwin > Assignee: Michael Irwin > Fix For: 2.1.0.Alpha3 > > > If using multiple browsers in a test, it would be nice to support multiple @InitialPage parameters in the method, each with a separate qualifier. > Obviously, if the same qualifier is applied to more than one @InitialPage, it should throw and prevent execution. > Pull-request incoming... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:01 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-482) Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-482: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.1-Tracking) > Screenshooter-onEveryAction: "RE: Error during saving the screenshot!" when "close()" or "quit()" is called > ----------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-482 > URL: https://issues.jboss.org/browse/ARQGRA-482 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 2.1.0.Alpha3 > > > When takeOnEveryAction is activated and either {{WebDriver.close()}} or {{WebDriver.quit()}} is called, then this exception is thrown: > {noformat} > java.lang.RuntimeException: Error during saving the screenshot! > at org.arquillian.extension.recorder.screenshooter.browser.impl.BrowserScreenshooter.takeScreenshot(BrowserScreenshooter.java:126) > at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotAndReportService.takeScreenshotAndReport(TakeScreenshotAndReportService.java:60) > at org.arquillian.extension.recorder.screenshooter.browser.impl.AbstractTakeScreenshotInterceptor.takeScreenshotAndReport(AbstractTakeScreenshotInterceptor.java:46) > at org.arquillian.extension.recorder.screenshooter.browser.impl.TakeScreenshotOnEveryActionInterceptor.intercept(TakeScreenshotOnEveryActionInterceptor.java:75) > at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:213) > at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:209) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:233) > at org.openqa.selenium.phantomjs.PhantomJSDriver$$EnhancerByGraphene$$8a745fde.close() > at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase$OnEveryActionManyActionsTestClass.testMethod(OnEveryActionScreenshotTestCase.java:135) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136) > at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > 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:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at org.junit.runner.JUnitCore.run(JUnitCore.java:128) > at org.junit.runner.JUnitCore.runClasses(JUnitCore.java:73) > at org.jboss.arquillian.graphene.screenshooter.ftest.when.AbstractScreenshotTestCase.runTest(AbstractScreenshotTestCase.java:53) > at org.jboss.arquillian.graphene.screenshooter.ftest.when.OnEveryActionScreenshotTestCase.onEveryActionManyActionsTest(OnEveryActionScreenshotTestCase.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > 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 org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: org.openqa.selenium.NoSuchWindowException: {"errorMessage":"Currently Window handle/name is invalid (closed?)","request":{"headers":{"Accept-Encoding":"gzip,deflate","Cache-Control":"no-cache","Connection":"Keep-Alive","Host":"localhost:8148","User-Agent":"Apache-HttpClient/4.4.1 (Java/1.8.0_05)"},"httpVersion":"1.1","method":"GET","url":"/screenshot","urlParsed":{"anchor":"","query":"","file":"screenshot","directory":"/","path":"/screenshot","relative":"/screenshot","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/screenshot","queryKey":{},"chunks":["screenshot"]},"urlOriginal":"/session/a57ad390-6c28-11e5-b917-2bceae0d5451/screenshot"}} > Command duration or timeout: 48 milliseconds > {noformat} > This behaviour is expected, because there nothing where the screenshot could be taken. Solution is to remove these two methods from the allowed list. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:02 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-468) Cannot use relative @Location when using "standalone" JUnit integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-468: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.1-Tracking) > Cannot use relative @Location when using "standalone" JUnit integration > ----------------------------------------------------------------------- > > Key: ARQGRA-468 > URL: https://issues.jboss.org/browse/ARQGRA-468 > Project: Arquillian Graphene > Issue Type: Bug > Components: configuration > Affects Versions: 2.1.0.Alpha2 > Reporter: Christoffer Bromberg > Assignee: Christoffer Bromberg > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > As per https://issues.jboss.org/browse/ARQGRA-374 one can use the arquillian.xml to specify a "contextRoot" for page objects that use a relative URL. > This feature does not work if you use the "Standalone Mode" as described here: https://docs.jboss.org/author/display/ARQGRA2/Framework+Integration+Options > After I switched to the "container" dependency it works as expected. > I don't use the deployment and container management feature of Arquillian and still the "container" dependency works without any hassle. So either the > {code} > > > org.jboss.arquillian.junit > arquillian-junit-standalone > test > > {code} > dependency should also include the correct classes (e.g. URLResourceProvider) or maybe the "Standalone" integration option is not (or no longer) needed. > So the workaround for me was to use the arquillian-junit-container dependency. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:02 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-469: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.0-Tracking) (was: 2.1-Tracking) > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Fix For: 2.1.0.Alpha3 > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:02 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-476) Extend root element from GrapheneElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-476: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.1-Tracking) > Extend root element from GrapheneElement > ----------------------------------------- > > Key: ARQGRA-476 > URL: https://issues.jboss.org/browse/ARQGRA-476 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Currently the root element in page fragments must extend WebElement. I would like to extend this, so it can also extend GrapheneElement. I'm preparing a pull request for this currently. Would be nice if this enhancement would make it to the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 20 03:03:02 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 20 Oct 2015 03:03:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-480: ------------------------------ Fix Version/s: 2.1.0.Alpha3 (was: 2.1-Tracking) > Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well > --------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-480 > URL: https://issues.jboss.org/browse/ARQGRA-480 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1.0.Alpha2 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 2.1.0.Alpha3 > > > Consider this scenario: > Arquillian.xml contains: > {code:xml} > > true > false > false > false > > {code} > Then, when the test starts this output is written there in the console log: > {noformat} > Configuration of Arquillian Browser Screenshooter: > rootDir target/screenshots > screenshotType PNG > takeBeforeTest true > takeAfterTest false > takeWhenTestFailed false > takeOnEveryAction true > {noformat} > There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there. > The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this: > 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979_tests/extension/screenshooter#arquillian-browser-screenshooter]) - this means not taking screenshots during the before phase > 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 22 05:23:00 2015 From: issues at jboss.org (Grzegorz Grzybek (JIRA)) Date: Thu, 22 Oct 2015 05:23:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120866#comment-13120866 ] Grzegorz Grzybek commented on ARQ-1940: --------------------------------------- The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18. With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.jboss.arquillian.junit.Arquillian.(Arquillian.java:50) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x2b5> (a java.lang.Object) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) {noformat} However mave-surefire 2.18 added: {code:java} runNotifier.fireTestRunStarted( createTestsDescription() ); {code} invocation before tests are started. And this leads to earler creation of Arquillian runner. 1st: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runner.Computer.getRunner(Computer.java:40) at org.junit.runner.Computer$1.runnerForClass(Computer.java:31) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87) at org.junit.runners.Suite.(Suite.java:81) at org.junit.runner.Computer.getSuite(Computer.java:28) at org.junit.runner.Request.classes(Request.java:75) at org.junit.runner.Request.classes(Request.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67) at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111) at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} 2nd: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x3ab> (a java.lang.Object) at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event. > arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 > --------------------------------------------------------------------------------- > > Key: ARQ-1940 > URL: https://issues.jboss.org/browse/ARQ-1940 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tomas Rohovsky > Priority: Minor > Attachments: surefire-reproducer.zip > > > arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 22 05:24:00 2015 From: issues at jboss.org (Grzegorz Grzybek (JIRA)) Date: Thu, 22 Oct 2015 05:24:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120866#comment-13120866 ] Grzegorz Grzybek edited comment on ARQ-1940 at 10/22/15 5:23 AM: ----------------------------------------------------------------- The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18. With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.jboss.arquillian.junit.Arquillian.(Arquillian.java:50) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x2b5> (a java.lang.Object) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) {noformat} However mave-surefire 2.18 added: {code:java} runNotifier.fireTestRunStarted( createTestsDescription() ); {code} invocation before tests are started. And this leads to double creation of Arquillian runner. 1st: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runner.Computer.getRunner(Computer.java:40) at org.junit.runner.Computer$1.runnerForClass(Computer.java:31) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87) at org.junit.runners.Suite.(Suite.java:81) at org.junit.runner.Computer.getSuite(Computer.java:28) at org.junit.runner.Request.classes(Request.java:75) at org.junit.runner.Request.classes(Request.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67) at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111) at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} 2nd: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x3ab> (a java.lang.Object) at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event. was (Author: grgrzybek): The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18. With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.jboss.arquillian.junit.Arquillian.(Arquillian.java:50) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x2b5> (a java.lang.Object) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) {noformat} However mave-surefire 2.18 added: {code:java} runNotifier.fireTestRunStarted( createTestsDescription() ); {code} invocation before tests are started. And this leads to earler creation of Arquillian runner. 1st: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runner.Computer.getRunner(Computer.java:40) at org.junit.runner.Computer$1.runnerForClass(Computer.java:31) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87) at org.junit.runners.Suite.(Suite.java:81) at org.junit.runner.Computer.getSuite(Computer.java:28) at org.junit.runner.Request.classes(Request.java:75) at org.junit.runner.Request.classes(Request.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67) at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111) at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} 2nd: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x3ab> (a java.lang.Object) at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event. > arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 > --------------------------------------------------------------------------------- > > Key: ARQ-1940 > URL: https://issues.jboss.org/browse/ARQ-1940 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tomas Rohovsky > Priority: Minor > Attachments: surefire-reproducer.zip > > > arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 22 05:25:00 2015 From: issues at jboss.org (Grzegorz Grzybek (JIRA)) Date: Thu, 22 Oct 2015 05:25:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120866#comment-13120866 ] Grzegorz Grzybek edited comment on ARQ-1940 at 10/22/15 5:24 AM: ----------------------------------------------------------------- The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18. With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.jboss.arquillian.junit.Arquillian.(Arquillian.java:50) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x2b5> (a java.lang.Object) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) {noformat} However mave-surefire 2.18 added: {code:java} runNotifier.fireTestRunStarted( createTestsDescription() ); {code} invocation before tests are started. And this leads to double creation of Arquillian runner. 1st: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runner.Computer.getRunner(Computer.java:40) at org.junit.runner.Computer$1.runnerForClass(Computer.java:31) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87) at org.junit.runners.Suite.(Suite.java:81) at org.junit.runner.Computer.getSuite(Computer.java:28) at org.junit.runner.Request.classes(Request.java:75) at org.junit.runner.Request.classes(Request.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67) at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111) at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} 2nd: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x3ab> (a java.lang.Object) at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event. (IMO this is rather bug in surefire, than in ARQ) was (Author: grgrzybek): The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18. With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.jboss.arquillian.junit.Arquillian.(Arquillian.java:50) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x2b5> (a java.lang.Object) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) {noformat} However mave-surefire 2.18 added: {code:java} runNotifier.fireTestRunStarted( createTestsDescription() ); {code} invocation before tests are started. And this leads to double creation of Arquillian runner. 1st: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runner.Computer.getRunner(Computer.java:40) at org.junit.runner.Computer$1.runnerForClass(Computer.java:31) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101) at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87) at org.junit.runners.Suite.(Suite.java:81) at org.junit.runner.Computer.getSuite(Computer.java:28) at org.junit.runner.Request.classes(Request.java:75) at org.junit.runner.Request.classes(Request.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67) at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111) at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} 2nd: {noformat} "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33) - locked <0x3ab> (a java.lang.Object) at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) {noformat} So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event. > arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 > --------------------------------------------------------------------------------- > > Key: ARQ-1940 > URL: https://issues.jboss.org/browse/ARQ-1940 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tomas Rohovsky > Priority: Minor > Attachments: surefire-reproducer.zip > > > arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 23 07:47:00 2015 From: issues at jboss.org (Tibor Digana (JIRA)) Date: Fri, 23 Oct 2015 07:47:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121440#comment-13121440 ] Tibor Digana commented on ARQ-1940: ----------------------------------- After the last discussion in [1] we understood the root cause and a new release is planned by the EO Oct, see [2] [1] https://issues.apache.org/jira/browse/SUREFIRE-1095 [2] https://issues.apache.org/jira/browse/SUREFIRE-1187 > arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 > --------------------------------------------------------------------------------- > > Key: ARQ-1940 > URL: https://issues.jboss.org/browse/ARQ-1940 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tomas Rohovsky > Priority: Minor > Attachments: surefire-reproducer.zip > > > arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 23 11:27:00 2015 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Fri, 23 Oct 2015 11:27:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1255) Multiple deployments is not working in Weld SE container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonin Stefanutti updated ARQ-1255: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-weld/pull/21 > Multiple deployments is not working in Weld SE container > -------------------------------------------------------- > > Key: ARQ-1255 > URL: https://issues.jboss.org/browse/ARQ-1255 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: 1.0.0.CR5 > Reporter: Antonin Stefanutti > Attachments: Bean1.java, Bean2.java, MultipleDeploymentArquilianCdiTest.java, OperateOnDeploymentArquilianCdiTest.java, pom.xml, test_case_1_stacktrace.txt, test_case_2_stacktrace.txt > > > As described in [Multiple Deployments|https://docs.jboss.org/author/display/ARQ/Multiple+Deployments], multiple {{@Deployment}} annotated methods can be declared in a test class. In addition, the {{@OperateOnDeployment}} annotation enables the selection of a particular _deployment_ per test method. > However, when using Arquillian with a Weld SE container, the CDI container isn't deployed with the expected archives which ends up having {{DeploymentException}} thrown, as illustrated in the test cases below: > *Test case 1:* > {code} > @RunWith(Arquillian.class) > public class MultipleDeploymentArquilianCdiTest { > @Inject > private Bean1 bean1; > @Inject > private Bean2 bean2; > @Deployment(name = "bean1-jar") > public static Archive createBean1Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean2-jar") > public static Archive createBean2Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Test > public void multiDeploymentTest() { > assertNotNull(bean1); > assertNotNull(bean2); > } > } > {code} > *Test case 2:* > {code} > @RunWith(Arquillian.class) > public class OperateOnDeploymentArquilianCdiTest { > @Inject > private Bean1 bean1; > @Inject > private Bean2 bean2; > @Deployment(name = "beans-jar") > public static Archive createBeansJar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean1-jar") > public static Archive createBean1Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean2-jar") > public static Archive createBean2Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Test > @OperateOnDeployment("beans-jar") > public void singleDeploymentTest() { > assertNotNull(bean1); > assertNotNull(bean2); > } > } > {code} > In both cases, the following exception is thrown: > {code} > org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bean2] with qualifiers [@Default] at injection point [[field] @Inject private arquillian.test.OperateOnDeploymentArquilianCdiTest.bean2] > {code} > Note that test case 2 is working when only {{@Deployment(name = "beans-jar")}} is declared. > Test classes and the {{pom.xml}} are attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 23 11:38:01 2015 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Fri, 23 Oct 2015 11:38:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1255) Multiple deployments is not working in Weld SE container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121614#comment-13121614 ] Antonin Stefanutti commented on ARQ-1255: ----------------------------------------- Test case is available here: https://github.com/astefanutti/arquillian-container-weld/blob/ARQ-1255/weld-se-embedded-2.1/src/test/java/org/jboss/arquillian/container/weld/se/embedded_1_1/WeldEmbeddedMultipleDeploymentTest.java It's available starting Weld version {{2.1.0.Final}} so that I created a new module {{weld-se-embedded-2.1}}. > Multiple deployments is not working in Weld SE container > -------------------------------------------------------- > > Key: ARQ-1255 > URL: https://issues.jboss.org/browse/ARQ-1255 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: 1.0.0.CR5 > Reporter: Antonin Stefanutti > Attachments: Bean1.java, Bean2.java, MultipleDeploymentArquilianCdiTest.java, OperateOnDeploymentArquilianCdiTest.java, pom.xml, test_case_1_stacktrace.txt, test_case_2_stacktrace.txt > > > As described in [Multiple Deployments|https://docs.jboss.org/author/display/ARQ/Multiple+Deployments], multiple {{@Deployment}} annotated methods can be declared in a test class. In addition, the {{@OperateOnDeployment}} annotation enables the selection of a particular _deployment_ per test method. > However, when using Arquillian with a Weld SE container, the CDI container isn't deployed with the expected archives which ends up having {{DeploymentException}} thrown, as illustrated in the test cases below: > *Test case 1:* > {code} > @RunWith(Arquillian.class) > public class MultipleDeploymentArquilianCdiTest { > @Inject > private Bean1 bean1; > @Inject > private Bean2 bean2; > @Deployment(name = "bean1-jar") > public static Archive createBean1Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean2-jar") > public static Archive createBean2Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Test > public void multiDeploymentTest() { > assertNotNull(bean1); > assertNotNull(bean2); > } > } > {code} > *Test case 2:* > {code} > @RunWith(Arquillian.class) > public class OperateOnDeploymentArquilianCdiTest { > @Inject > private Bean1 bean1; > @Inject > private Bean2 bean2; > @Deployment(name = "beans-jar") > public static Archive createBeansJar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean1-jar") > public static Archive createBean1Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Deployment(name = "bean2-jar") > public static Archive createBean2Jar() { > return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @Test > @OperateOnDeployment("beans-jar") > public void singleDeploymentTest() { > assertNotNull(bean1); > assertNotNull(bean2); > } > } > {code} > In both cases, the following exception is thrown: > {code} > org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bean2] with qualifiers [@Default] at injection point [[field] @Inject private arquillian.test.OperateOnDeploymentArquilianCdiTest.bean2] > {code} > Note that test case 2 is working when only {{@Deployment(name = "beans-jar")}} is declared. > Test classes and the {{pom.xml}} are attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 27 15:55:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 27 Oct 2015 15:55:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1996) Upgrade to ShrinkWrap 1.2.3 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1996: ---------------------------------- Summary: Upgrade to ShrinkWrap 1.2.3 Key: ARQ-1996 URL: https://issues.jboss.org/browse/ARQ-1996 Project: Arquillian Issue Type: Component Upgrade Components: Base Implementation Affects Versions: 1.1.10.Final Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.2.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 27 15:59:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 27 Oct 2015 15:59:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1996) Upgrade to ShrinkWrap 1.2.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1996: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/95 > Upgrade to ShrinkWrap 1.2.3 > --------------------------- > > Key: ARQ-1996 > URL: https://issues.jboss.org/browse/ARQ-1996 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.10.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 27 15:59:00 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 27 Oct 2015 15:59:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1996) Upgrade to ShrinkWrap 1.2.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1996: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/0733d0b9fb3281c64d92054551b49a220d2f53fd > Upgrade to ShrinkWrap 1.2.3 > --------------------------- > > Key: ARQ-1996 > URL: https://issues.jboss.org/browse/ARQ-1996 > Project: Arquillian > Issue Type: Component Upgrade > Components: Base Implementation > Affects Versions: 1.1.10.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)