From issues at jboss.org Tue Jul 1 02:58:24 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 02:58:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-446) Add support for Groovy page objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-446: ------------------------------ Fix Version/s: 2.1.0.Alpha1 > Add support for Groovy page objects > ----------------------------------- > > Key: ARQGRA-446 > URL: https://issues.jboss.org/browse/ARQGRA-446 > Project: Arquillian Graphene > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: configuration, core > Affects Versions: 2.0.2.Final > Reporter: Chris Jones > Fix For: 2.1.0.Alpha1 > > Attachments: graphene-groovy-test.zip, groovy-page-support (fixed paths).patch, groovy-page-support.patch > > > Page objects written in groovy throw a StackOverflowError. There seems to be a recursive issue when proxying groovy's metaclass property. > {code:title=GoogleGroovy.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.graphene.page.Location > import org.openqa.selenium.WebElement > import org.openqa.selenium.support.FindBy > @Location("https://www.google.com/") > public class GoogleGroovy { > @FindBy > WebElement q > def search(String query){ > q.sendKeys(query) > sleep(5000) > } > } > {code} > {code:title=GoogleJava.java|borderStyle=solid} > package test; > import org.jboss.arquillian.graphene.page.Location; > import org.openqa.selenium.WebElement; > import org.openqa.selenium.support.FindBy; > @Location("https://www.google.com/") > public class GoogleJava { > @FindBy > WebElement q; > public void search(String query) throws Exception { > q.sendKeys(query); > Thread.sleep(5000); > } > } > {code} > {code:title=GoogleTestCase.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.drone.api.annotation.Drone > import org.jboss.arquillian.graphene.Graphene > import org.jboss.arquillian.junit.Arquillian > import org.junit.Test > import org.junit.runner.RunWith > import org.openqa.selenium.firefox.FirefoxDriver > @RunWith(Arquillian.class) > class GoogleTestCase { > @Drone > FirefoxDriver driver > @Test > def void testUsingJava(){ > def googleJava = Graphene.goTo(GoogleJava) > googleJava.search("hello world") > } > @Test > def void testUsingGroovy(){ > def googleGroovy = Graphene.goTo(GoogleGroovy) > googleGroovy.search("jello world") > } > } > {code} > {code:title=Stacktrace|borderStyle=solid} > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597979243' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > java.lang.StackOverflowError > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:205) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:229) > at test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8.getMetaClass() > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.checkCall(PogoMetaClassSite.java:59) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:36) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > ..... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 07:02:25 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Tue, 1 Jul 2014 07:02:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980921#comment-12980921 ] Stephen Coy commented on ARQ-600: --------------------------------- {code:java}org.jboss.arquillian.container.tomcat.managed_6.TomcatManagedConfiguration{code} contains a serverName attribute that does not appear in the other container configurations. Should I remove this or propagate it to the other managed container configurations? > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 08:04:28 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 08:04:28 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980950#comment-12980950 ] Aslak Knutsen commented on ARQ-600: ----------------------------------- If it's useful to the others; propagate If not, let managed_6.TomcatManagedConfiguration extend the Common one ? > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 08:22:28 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Tue, 1 Jul 2014 08:22:28 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980966#comment-12980966 ] Stephen Coy commented on ARQ-600: --------------------------------- It seems to be dead code. The 5.5, 6 and 7 TomcatManagedConfiguration classes were all functionally identical aside from this in 6. I'm going to remove it for now. > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 08:28:24 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Tue, 1 Jul 2014 08:28:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980972#comment-12980972 ] Stephen Coy commented on ARQ-600: --------------------------------- The embedded containers seem to have this attribute, which they use to name the Tomcat Engine component that would be named via a server.xml file in the managed case. > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 08:28:24 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Tue, 1 Jul 2014 08:28:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980972#comment-12980972 ] Stephen Coy edited comment on ARQ-600 at 7/1/14 8:28 AM: --------------------------------------------------------- The embedded containers seem to have this attribute, which they use to name the Tomcat Engine component that would be named via a server.xml file in the managed case. So I suspect it was a copy/paste thing that stuck around was (Author: sfcoy): The embedded containers seem to have this attribute, which they use to name the Tomcat Engine component that would be named via a server.xml file in the managed case. > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:18:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 09:18:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1811) Support non Warp annotations on Lifecycle methods In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1811: ---------------------------------- Summary: Support non Warp annotations on Lifecycle methods Key: ARQ-1811 URL: https://issues.jboss.org/browse/ARQ-1811 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Aslak Knutsen 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.2.6#6264) From issues at jboss.org Tue Jul 1 09:18:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 09:18:24 -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 ] Aslak Knutsen updated ARQ-1811: ------------------------------- Affects Version/s: warp_1.0.0.Alpha7 > Support non Warp annotations on Lifecycle methods > ------------------------------------------------- > > Key: ARQ-1811 > URL: https://issues.jboss.org/browse/ARQ-1811 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > > 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.2.6#6264) From issues at jboss.org Tue Jul 1 09:18:25 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 09:18:25 -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 ] Aslak Knutsen updated ARQ-1811: ------------------------------- Component/s: Extension - Warp > Support non Warp annotations on Lifecycle methods > ------------------------------------------------- > > Key: ARQ-1811 > URL: https://issues.jboss.org/browse/ARQ-1811 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > > 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.2.6#6264) From issues at jboss.org Tue Jul 1 09:54:25 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Tue, 1 Jul 2014 09:54:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Coy updated ARQ-600: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-tomcat/pull/25 > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:58:24 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 09:58:24 -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: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 > Support non Warp annotations on Lifecycle methods > ------------------------------------------------- > > Key: ARQ-1811 > URL: https://issues.jboss.org/browse/ARQ-1811 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Tue Jul 1 10:08:24 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:08:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1769) org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971195#comment-12971195 ] Luk?? Fry? edited comment on ARQ-1769 at 7/1/14 10:06 AM: ---------------------------------------------------------- Lukas, For some reason when I posted the code I left out the inspection. My apologies. Here it is: {code} browser.navigate().to("http://localhost:8080/test/" + INITIAL_PAGE); Warp.initiate(new Activity() { public void perform() { WebElement element = browser.findElement(By.name("f")); element.submit(); } }).group().observe(request()).inspect(new Inspection() { private static final long serialVersionUID = -5222424427892601639L; @ArquillianResource private HttpServletResponse response; @AfterPhase(Phase.RESTORE_VIEW) public void verify_that_the_appropriate_page_is_requested(@ArquillianResource FacesContext facesContext) { Assert.assertEquals(INITIAL_PAGE, facesContext.getViewRoot().getViewId()); } @AfterServlet public void verify_that_response_is_redirected() { Assert.assertTrue(response.getHeader("Location").contains(AFTER_LOGIN_PAGE)); } }) .execute(); {code} was (Author: bcrowell2): Lukas, For some reason when I posted the code I left out the inspection. My apologies. Here it is: browser.navigate().to("http://localhost:8080/test/" + INITIAL_PAGE); Warp.initiate(new Activity() { public void perform() { WebElement element = browser.findElement(By.name("f")); element.submit(); } }).group().observe(request()).inspect(new Inspection() { private static final long serialVersionUID = -5222424427892601639L; @ArquillianResource private HttpServletResponse response; @AfterPhase(Phase.RESTORE_VIEW) public void verify_that_the_appropriate_page_is_requested(@ArquillianResource FacesContext facesContext) { Assert.assertEquals(INITIAL_PAGE, facesContext.getViewRoot().getViewId()); } @AfterServlet public void verify_that_response_is_redirected() { Assert.assertTrue(response.getHeader("Location").contains(AFTER_LOGIN_PAGE)); } }) .execute(); > org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > -------------------------------------------------------------------------- > > Key: ARQ-1769 > URL: https://issues.jboss.org/browse/ARQ-1769 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, 1.1.3.Final, 1.1.4.Final > Environment: Windows 7 Enterprise SP1 64-bit > Reporter: William Crowell > > I am using the following: > Arquillian Core: 1.1.4.Final (as well as 1.1.3.Final) > Arquillian Drone: 1.2.4.Final (I've tried Drone 2 as well) > Arquillian Warp: 1.0.0.Alpha7 (as well as 1.0.0.Beta1-SNAPSHOT) > Arquillian Transaction: 1.0.1.Final > Arquillian Tomcat 7 Embedded Container using Tomcat 7.0.27: 1.0.0.Final-SNAPSHOT > Spring: 3.2.4.RELEASE > Spring Web: 3.2.2.RELEASE > Spring Security: 3.1.4.RELEASE > Spring WebFlow: 2.4.0.RC1 > PrimeFaces 3.4.2 > JUnit: 4.8.2 > Mojarra 2.1.17 > I am receiving this exception: > {code} > java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:69) > ... > 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.warp.impl.server.test.LifecycleTestClassExecutor.afterRequest(LifecycleTestClassExecutor.java:78) > ... > 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.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.request.RequestContextHandler.handleRequestContext(RequestContextHandler.java:93) > ... > 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.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:151) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:120) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:93) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:183) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) > at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > ... > Caused by: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.checkUnbound(LifecycleManagerStoreImpl.java:126) > at org.jboss.arquillian.warp.spi.LifecycleManager.checkUnbound(LifecycleManager.java:158) > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:67) > ... 74 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:08:25 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:08:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1769) org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971427#comment-12971427 ] Luk?? Fry? edited comment on ARQ-1769 at 7/1/14 10:07 AM: ---------------------------------------------------------- I moved to phantomjs but I still have the issue. I don't think it is an issue with the client-side code runner but I will still move to phantomjs regardless. Using 1.0.0.Alpha7, the test WAR application starts up; however, the first request (using the driver.navigate().to("http://localhost:8080...") to the application gives the org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException. If I set a breakpoint in the test case and open a browser and hit the URL directly I get the same StoreHasAssociatedObjectsException. In org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl on line 126 I see this check in checkUnbound(LifecycleManager): {code} @Override protected void checkUnbound(LifecycleManager manager) throws StoreHasAssociatedObjectsException { Tracking tracking = TRACK.get(manager); if (tracking != null) { if (!tracking.isEmpty()) { throw new StoreHasAssociatedObjectsException(); } TRACK.remove(manager); } } {code} The tracking HashMap has an object with the key name "class javax.faces.context.FacesContext". However, 1.0.0.Alpha6, has different behavior. The first request works and the Activity inner classes' perform() method gets called, but the inspect inner class never gets called even though we match for all requests: {code} group().observe(request()).inspect(new Inspection()... {code} Then org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses() just sits until the arquillian.warp.synchronization.timeout (default of 5 seconds) expires: {code} ... (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AfterRequest (I) LifecycleTestClassExecutor.afterRequest (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AwaitResponse (O) WarpExecutionObserver.awaitResponse ... {code} I looked at the jsf-ftest sample code on github to see if I was missing something. I see some archives like arquillian-warp-jsf that contain a fragment for faces-config.xml. It defines a WarpPhaseListener and a FacesContextFactoryWrapper. I included arquillian-warp-jsf in my pom.xml but the problem remained. I have one of two possible theories here: 1) I am missing a dependency which binds/unbinds the FacesContext. 2) Is it possible that Arquillian Warp does not support PrimeFaces and/or Spring WebFlow? I see quite a bit of support for RichFaces. Maybe an adapter needs to be written for PrimeFaces. Not sure. was (Author: bcrowell2): I moved to phantomjs but I still have the issue. I don't think it is an issue with the client-side code runner but I will still move to phantomjs regardless. Using 1.0.0.Alpha7, the test WAR application starts up; however, the first request (using the driver.navigate().to("http://localhost:8080...") to the application gives the org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException. If I set a breakpoint in the test case and open a browser and hit the URL directly I get the same StoreHasAssociatedObjectsException. In org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl on line 126 I see this check in checkUnbound(LifecycleManager): @Override protected void checkUnbound(LifecycleManager manager) throws StoreHasAssociatedObjectsException { Tracking tracking = TRACK.get(manager); if (tracking != null) { if (!tracking.isEmpty()) { throw new StoreHasAssociatedObjectsException(); } TRACK.remove(manager); } } The tracking HashMap has an object with the key name "class javax.faces.context.FacesContext". However, 1.0.0.Alpha6, has different behavior. The first request works and the Activity inner classes' perform() method gets called, but the inspect inner class never gets called even though we match for all requests: group().observe(request()).inspect(new Inspection()... Then org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses() just sits until the arquillian.warp.synchronization.timeout (default of 5 seconds) expires: ... (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AfterRequest (I) LifecycleTestClassExecutor.afterRequest (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AwaitResponse (O) WarpExecutionObserver.awaitResponse ... I looked at the jsf-ftest sample code on github to see if I was missing something. I see some archives like arquillian-warp-jsf that contain a fragment for faces-config.xml. It defines a WarpPhaseListener and a FacesContextFactoryWrapper. I included arquillian-warp-jsf in my pom.xml but the problem remained. I have one of two possible theories here: 1) I am missing a dependency which binds/unbinds the FacesContext. 2) Is it possible that Arquillian Warp does not support PrimeFaces and/or Spring WebFlow? I see quite a bit of support for RichFaces. Maybe an adapter needs to be written for PrimeFaces. Not sure. > org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > -------------------------------------------------------------------------- > > Key: ARQ-1769 > URL: https://issues.jboss.org/browse/ARQ-1769 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, 1.1.3.Final, 1.1.4.Final > Environment: Windows 7 Enterprise SP1 64-bit > Reporter: William Crowell > > I am using the following: > Arquillian Core: 1.1.4.Final (as well as 1.1.3.Final) > Arquillian Drone: 1.2.4.Final (I've tried Drone 2 as well) > Arquillian Warp: 1.0.0.Alpha7 (as well as 1.0.0.Beta1-SNAPSHOT) > Arquillian Transaction: 1.0.1.Final > Arquillian Tomcat 7 Embedded Container using Tomcat 7.0.27: 1.0.0.Final-SNAPSHOT > Spring: 3.2.4.RELEASE > Spring Web: 3.2.2.RELEASE > Spring Security: 3.1.4.RELEASE > Spring WebFlow: 2.4.0.RC1 > PrimeFaces 3.4.2 > JUnit: 4.8.2 > Mojarra 2.1.17 > I am receiving this exception: > {code} > java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:69) > ... > 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.warp.impl.server.test.LifecycleTestClassExecutor.afterRequest(LifecycleTestClassExecutor.java:78) > ... > 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.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.request.RequestContextHandler.handleRequestContext(RequestContextHandler.java:93) > ... > 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.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:151) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:120) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:93) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:183) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) > at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > ... > Caused by: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.checkUnbound(LifecycleManagerStoreImpl.java:126) > at org.jboss.arquillian.warp.spi.LifecycleManager.checkUnbound(LifecycleManager.java:158) > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:67) > ... 74 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:10:25 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:10:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1769) org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971427#comment-12971427 ] Luk?? Fry? edited comment on ARQ-1769 at 7/1/14 10:08 AM: ---------------------------------------------------------- I moved to phantomjs but I still have the issue. I don't think it is an issue with the client-side code runner but I will still move to phantomjs regardless. Using 1.0.0.Alpha7, the test WAR application starts up; however, the first request (using the {{driver.navigate().to("http://localhost:8080...")}} to the application gives the {{StoreHasAssociatedObjectsException}}. If I set a breakpoint in the test case and open a browser and hit the URL directly I get the same {{StoreHasAssociatedObjectsException}}. In org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl on line 126 I see this check in checkUnbound(LifecycleManager): {code} @Override protected void checkUnbound(LifecycleManager manager) throws StoreHasAssociatedObjectsException { Tracking tracking = TRACK.get(manager); if (tracking != null) { if (!tracking.isEmpty()) { throw new StoreHasAssociatedObjectsException(); } TRACK.remove(manager); } } {code} The tracking HashMap has an object with the key name "class javax.faces.context.FacesContext". However, 1.0.0.Alpha6, has different behavior. The first request works and the Activity inner classes' perform() method gets called, but the inspect inner class never gets called even though we match for all requests: {code} group().observe(request()).inspect(new Inspection()... {code} Then org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses() just sits until the arquillian.warp.synchronization.timeout (default of 5 seconds) expires: {code} ... (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AfterRequest (I) LifecycleTestClassExecutor.afterRequest (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AwaitResponse (O) WarpExecutionObserver.awaitResponse ... {code} I looked at the jsf-ftest sample code on github to see if I was missing something. I see some archives like arquillian-warp-jsf that contain a fragment for faces-config.xml. It defines a WarpPhaseListener and a FacesContextFactoryWrapper. I included arquillian-warp-jsf in my pom.xml but the problem remained. I have one of two possible theories here: 1) I am missing a dependency which binds/unbinds the FacesContext. 2) Is it possible that Arquillian Warp does not support PrimeFaces and/or Spring WebFlow? I see quite a bit of support for RichFaces. Maybe an adapter needs to be written for PrimeFaces. Not sure. was (Author: bcrowell2): I moved to phantomjs but I still have the issue. I don't think it is an issue with the client-side code runner but I will still move to phantomjs regardless. Using 1.0.0.Alpha7, the test WAR application starts up; however, the first request (using the driver.navigate().to("http://localhost:8080...") to the application gives the org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException. If I set a breakpoint in the test case and open a browser and hit the URL directly I get the same StoreHasAssociatedObjectsException. In org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl on line 126 I see this check in checkUnbound(LifecycleManager): {code} @Override protected void checkUnbound(LifecycleManager manager) throws StoreHasAssociatedObjectsException { Tracking tracking = TRACK.get(manager); if (tracking != null) { if (!tracking.isEmpty()) { throw new StoreHasAssociatedObjectsException(); } TRACK.remove(manager); } } {code} The tracking HashMap has an object with the key name "class javax.faces.context.FacesContext". However, 1.0.0.Alpha6, has different behavior. The first request works and the Activity inner classes' perform() method gets called, but the inspect inner class never gets called even though we match for all requests: {code} group().observe(request()).inspect(new Inspection()... {code} Then org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses() just sits until the arquillian.warp.synchronization.timeout (default of 5 seconds) expires: {code} ... (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AfterRequest (I) LifecycleTestClassExecutor.afterRequest (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AwaitResponse (O) WarpExecutionObserver.awaitResponse ... {code} I looked at the jsf-ftest sample code on github to see if I was missing something. I see some archives like arquillian-warp-jsf that contain a fragment for faces-config.xml. It defines a WarpPhaseListener and a FacesContextFactoryWrapper. I included arquillian-warp-jsf in my pom.xml but the problem remained. I have one of two possible theories here: 1) I am missing a dependency which binds/unbinds the FacesContext. 2) Is it possible that Arquillian Warp does not support PrimeFaces and/or Spring WebFlow? I see quite a bit of support for RichFaces. Maybe an adapter needs to be written for PrimeFaces. Not sure. > org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > -------------------------------------------------------------------------- > > Key: ARQ-1769 > URL: https://issues.jboss.org/browse/ARQ-1769 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, 1.1.3.Final, 1.1.4.Final > Environment: Windows 7 Enterprise SP1 64-bit > Reporter: William Crowell > > I am using the following: > Arquillian Core: 1.1.4.Final (as well as 1.1.3.Final) > Arquillian Drone: 1.2.4.Final (I've tried Drone 2 as well) > Arquillian Warp: 1.0.0.Alpha7 (as well as 1.0.0.Beta1-SNAPSHOT) > Arquillian Transaction: 1.0.1.Final > Arquillian Tomcat 7 Embedded Container using Tomcat 7.0.27: 1.0.0.Final-SNAPSHOT > Spring: 3.2.4.RELEASE > Spring Web: 3.2.2.RELEASE > Spring Security: 3.1.4.RELEASE > Spring WebFlow: 2.4.0.RC1 > PrimeFaces 3.4.2 > JUnit: 4.8.2 > Mojarra 2.1.17 > I am receiving this exception: > {code} > java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:69) > ... > 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.warp.impl.server.test.LifecycleTestClassExecutor.afterRequest(LifecycleTestClassExecutor.java:78) > ... > 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.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.request.RequestContextHandler.handleRequestContext(RequestContextHandler.java:93) > ... > 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.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:151) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:120) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:93) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:183) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) > at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > ... > Caused by: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.checkUnbound(LifecycleManagerStoreImpl.java:126) > at org.jboss.arquillian.warp.spi.LifecycleManager.checkUnbound(LifecycleManager.java:158) > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:67) > ... 74 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:10:25 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:10:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1769) org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971427#comment-12971427 ] Luk?? Fry? edited comment on ARQ-1769 at 7/1/14 10:09 AM: ---------------------------------------------------------- I moved to phantomjs but I still have the issue. I don't think it is an issue with the client-side code runner but I will still move to phantomjs regardless. Using 1.0.0.Alpha7, the test WAR application starts up; however, the first request (using the {{driver.navigate().to("http://localhost:8080...")}} to the application gives the {{StoreHasAssociatedObjectsException}}. If I set a breakpoint in the test case and open a browser and hit the URL directly I get the same {{StoreHasAssociatedObjectsException}}. In {{LifecycleManagerStoreImpl}} on line 126 I see this check in {{checkUnbound(LifecycleManager)}}: {code} @Override protected void checkUnbound(LifecycleManager manager) throws StoreHasAssociatedObjectsException { Tracking tracking = TRACK.get(manager); if (tracking != null) { if (!tracking.isEmpty()) { throw new StoreHasAssociatedObjectsException(); } TRACK.remove(manager); } } {code} The tracking HashMap has an object with the key name "class javax.faces.context.FacesContext". However, 1.0.0.Alpha6, has different behavior. The first request works and the Activity inner classes' perform() method gets called, but the inspect inner class never gets called even though we match for all requests: {code} group().observe(request()).inspect(new Inspection()... {code} Then org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses() just sits until the arquillian.warp.synchronization.timeout (default of 5 seconds) expires: {code} ... (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AfterRequest (I) LifecycleTestClassExecutor.afterRequest (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AwaitResponse (O) WarpExecutionObserver.awaitResponse ... {code} I looked at the jsf-ftest sample code on github to see if I was missing something. I see some archives like arquillian-warp-jsf that contain a fragment for faces-config.xml. It defines a WarpPhaseListener and a FacesContextFactoryWrapper. I included arquillian-warp-jsf in my pom.xml but the problem remained. I have one of two possible theories here: 1) I am missing a dependency which binds/unbinds the FacesContext. 2) Is it possible that Arquillian Warp does not support PrimeFaces and/or Spring WebFlow? I see quite a bit of support for RichFaces. Maybe an adapter needs to be written for PrimeFaces. Not sure. was (Author: bcrowell2): I moved to phantomjs but I still have the issue. I don't think it is an issue with the client-side code runner but I will still move to phantomjs regardless. Using 1.0.0.Alpha7, the test WAR application starts up; however, the first request (using the {{driver.navigate().to("http://localhost:8080...")}} to the application gives the {{StoreHasAssociatedObjectsException}}. If I set a breakpoint in the test case and open a browser and hit the URL directly I get the same {{StoreHasAssociatedObjectsException}}. In org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl on line 126 I see this check in checkUnbound(LifecycleManager): {code} @Override protected void checkUnbound(LifecycleManager manager) throws StoreHasAssociatedObjectsException { Tracking tracking = TRACK.get(manager); if (tracking != null) { if (!tracking.isEmpty()) { throw new StoreHasAssociatedObjectsException(); } TRACK.remove(manager); } } {code} The tracking HashMap has an object with the key name "class javax.faces.context.FacesContext". However, 1.0.0.Alpha6, has different behavior. The first request works and the Activity inner classes' perform() method gets called, but the inspect inner class never gets called even though we match for all requests: {code} group().observe(request()).inspect(new Inspection()... {code} Then org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses() just sits until the arquillian.warp.synchronization.timeout (default of 5 seconds) expires: {code} ... (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AfterRequest (I) LifecycleTestClassExecutor.afterRequest (E) PassivateManager (I) ManagerActivationObserver.deactivateApplicationContext (E) AwaitResponse (O) WarpExecutionObserver.awaitResponse ... {code} I looked at the jsf-ftest sample code on github to see if I was missing something. I see some archives like arquillian-warp-jsf that contain a fragment for faces-config.xml. It defines a WarpPhaseListener and a FacesContextFactoryWrapper. I included arquillian-warp-jsf in my pom.xml but the problem remained. I have one of two possible theories here: 1) I am missing a dependency which binds/unbinds the FacesContext. 2) Is it possible that Arquillian Warp does not support PrimeFaces and/or Spring WebFlow? I see quite a bit of support for RichFaces. Maybe an adapter needs to be written for PrimeFaces. Not sure. > org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > -------------------------------------------------------------------------- > > Key: ARQ-1769 > URL: https://issues.jboss.org/browse/ARQ-1769 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, 1.1.3.Final, 1.1.4.Final > Environment: Windows 7 Enterprise SP1 64-bit > Reporter: William Crowell > > I am using the following: > Arquillian Core: 1.1.4.Final (as well as 1.1.3.Final) > Arquillian Drone: 1.2.4.Final (I've tried Drone 2 as well) > Arquillian Warp: 1.0.0.Alpha7 (as well as 1.0.0.Beta1-SNAPSHOT) > Arquillian Transaction: 1.0.1.Final > Arquillian Tomcat 7 Embedded Container using Tomcat 7.0.27: 1.0.0.Final-SNAPSHOT > Spring: 3.2.4.RELEASE > Spring Web: 3.2.2.RELEASE > Spring Security: 3.1.4.RELEASE > Spring WebFlow: 2.4.0.RC1 > PrimeFaces 3.4.2 > JUnit: 4.8.2 > Mojarra 2.1.17 > I am receiving this exception: > {code} > java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:69) > ... > 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.warp.impl.server.test.LifecycleTestClassExecutor.afterRequest(LifecycleTestClassExecutor.java:78) > ... > 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.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.request.RequestContextHandler.handleRequestContext(RequestContextHandler.java:93) > ... > 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.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:151) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:120) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:93) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:183) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) > at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > ... > Caused by: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.checkUnbound(LifecycleManagerStoreImpl.java:126) > at org.jboss.arquillian.warp.spi.LifecycleManager.checkUnbound(LifecycleManager.java:158) > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:67) > ... 74 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:14:25 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:14:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1560) Having Warp in Classpath causes NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1560. ----------------------------- Assignee: Luk?? Fry? Resolution: Incomplete Description I'm rejecting this issue for incomplete description. Feel free to reopen with more information. > Having Warp in Classpath causes NPE > ----------------------------------- > > Key: ARQ-1560 > URL: https://issues.jboss.org/browse/ARQ-1560 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Environment: Windows 8 64 Bit Jboss 7.1.1 > Reporter: Lukas Eichler > Assignee: Luk?? Fry? > > This basic test creates a NPE for having Wrap in the classpath and not containing a @Deployment method. Although it isn't a wrap test it gets treated as one. > {code} > @RunWith(Arquillian.class) > public class BasicTest { > @Drone > WebDriver browser; > @ArquillianResource > URL deploymentPath; > @Test > public void firstTest() throws Exception { > browser.navigate().to("http://google.com"); > assertEquals("Google", browser.getTitle()); > } > } > {code} > {code} > Stacktrace > java.lang.NullPointerException > at org.jboss.arquillian.warp.impl.client.proxy.ProxyURLProvider.lookup(ProxyURLProvider.java:70) > at org.jboss.arquillian.graphene.location.ContextRootStoreInitializer.getContextRoot(ContextRootStoreInitializer.java:54) > at org.jboss.arquillian.graphene.location.ContextRootStoreInitializer.setupLocationForClass(ContextRootStoreInitializer.java:47) > 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: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.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:48) > 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 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 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 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 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 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.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > 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:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77) > at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:121) > java.lang.IllegalStateException: Unexpected callable present in Drone Context, should be already instantiated at this moment. > at org.jboss.arquillian.drone.impl.InstanceOrCallableInstanceImpl.asInstance(InstanceOrCallableInstanceImpl.java:57) > at org.jboss.arquillian.drone.impl.DroneEnhancer.deenhanceDrone(DroneEnhancer.java:119) > 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: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.drone.impl.DroneDestructor.destroyClassScopedDrone(DroneDestructor.java:83) > 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.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 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 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.afterClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:204) > 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:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77) > at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:121) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:14:26 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:14:26 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1627) Warp: refactor fluent observer specification API for clarity In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1627: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 > Warp: refactor fluent observer specification API for clarity > ------------------------------------------------------------ > > Key: ARQ-1627 > URL: https://issues.jboss.org/browse/ARQ-1627 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > > {code} > request().header("Content-Type").equalTo("application/json"); > request().parameter().containsValue("id", "12345"); > {code} > should be > {code} > request().header("Content-Type").equalTo("application/json"); > request().parameter("id").contains("12345"); > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:14:26 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:14:26 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1769) org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1769: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 > org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > -------------------------------------------------------------------------- > > Key: ARQ-1769 > URL: https://issues.jboss.org/browse/ARQ-1769 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, 1.1.3.Final, 1.1.4.Final > Environment: Windows 7 Enterprise SP1 64-bit > Reporter: William Crowell > Fix For: warp_1.0.0.Beta1 > > > I am using the following: > Arquillian Core: 1.1.4.Final (as well as 1.1.3.Final) > Arquillian Drone: 1.2.4.Final (I've tried Drone 2 as well) > Arquillian Warp: 1.0.0.Alpha7 (as well as 1.0.0.Beta1-SNAPSHOT) > Arquillian Transaction: 1.0.1.Final > Arquillian Tomcat 7 Embedded Container using Tomcat 7.0.27: 1.0.0.Final-SNAPSHOT > Spring: 3.2.4.RELEASE > Spring Web: 3.2.2.RELEASE > Spring Security: 3.1.4.RELEASE > Spring WebFlow: 2.4.0.RC1 > PrimeFaces 3.4.2 > JUnit: 4.8.2 > Mojarra 2.1.17 > I am receiving this exception: > {code} > java.lang.IllegalStateException: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:69) > ... > 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.warp.impl.server.test.LifecycleTestClassExecutor.afterRequest(LifecycleTestClassExecutor.java:78) > ... > 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.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.warp.impl.server.request.RequestContextHandler.handleRequestContext(RequestContextHandler.java:93) > ... > 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.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:151) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:120) > at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:93) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) > at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:183) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) > at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > ... > Caused by: org.jboss.arquillian.warp.spi.exception.StoreHasAssociatedObjectsException > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerStoreImpl.checkUnbound(LifecycleManagerStoreImpl.java:126) > at org.jboss.arquillian.warp.spi.LifecycleManager.checkUnbound(LifecycleManager.java:158) > at org.jboss.arquillian.warp.impl.server.lifecycle.LifecycleManagerObserver.finalizeManager(LifecycleManagerObserver.java:67) > ... 74 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:16:28 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 10:16:28 -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? updated ARQ-1617: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 > Warp: reconsider httpcore dependency of Warp impl > ------------------------------------------------- > > Key: ARQ-1617 > URL: https://issues.jboss.org/browse/ARQ-1617 > Project: Arquillian > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > > 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.2.6#6264) From issues at jboss.org Tue Jul 1 13:02:24 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 1 Jul 2014 13:02:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-449) Graphene can not switch between contexts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-449: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Graphene can not switch between contexts > ---------------------------------------- > > Key: ARQGRA-449 > URL: https://issues.jboss.org/browse/ARQGRA-449 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: 2.0.4.Final > > > This code: > {code} > @Test > public void nativeViewTest() > { > driver.switchTo().window("NATIVE_APP"); > } > {code} > That window() parameter is Selendroid-related and it has nothing to do with Graphene. Graphene is just not able to handle that. > It produces this exception: > {code} > java.lang.IllegalArgumentException: methods with same signature getContext() but incompatible return types: [class java.lang.String, class org.jboss.arquillian.graphene.context.GrapheneContext] > at sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:686) > at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:437) > at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:323) > at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:636) > at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:722) > at org.jboss.arquillian.graphene.proxy.GrapheneProxy.createProxy(GrapheneProxy.java:166) > at org.jboss.arquillian.graphene.proxy.GrapheneProxy.getProxyForTargetWithInterfaces(GrapheneProxy.java:92) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$1.invoke(GrapheneContextualHandler.java:165) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:209) > at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:205) > at com.sun.proxy.$Proxy27.window(Unknown Source) > at org.arquillian.droidium.showcase.hybrid.test01.SelendroidHybridTestAppTestCase.nativeViewTest(SelendroidHybridTestAppTestCase.java:101) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:34:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 16:34:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1812) Add Jersey Client support In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1812: ---------------------------------- Summary: Add Jersey Client support Key: ARQ-1812 URL: https://issues.jboss.org/browse/ARQ-1812 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - REST Affects Versions: rest_1.0.0.Alpha2 Reporter: Aslak Knutsen Fix For: rest_1.0.0.Alpha3 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:34:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 16:34:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1812) Add Jersey Client support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1812: ------------------------------- Assignee: Bernard Labno > Add Jersey Client support > ------------------------- > > Key: ARQ-1812 > URL: https://issues.jboss.org/browse/ARQ-1812 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - REST > Affects Versions: rest_1.0.0.Alpha2 > Reporter: Aslak Knutsen > Assignee: Bernard Labno > Fix For: rest_1.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:34:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 16:34:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1812) Add Jersey Client support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1812: ------------------------------- Status: Closed (was: Pull Request Sent) Resolution: Done > Add Jersey Client support > ------------------------- > > Key: ARQ-1812 > URL: https://issues.jboss.org/browse/ARQ-1812 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - REST > Affects Versions: rest_1.0.0.Alpha2 > Reporter: Aslak Knutsen > Assignee: Bernard Labno > Fix For: rest_1.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:34:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 16:34:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1812) Add Jersey Client support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1812: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-rest/pull/17/ > Add Jersey Client support > ------------------------- > > Key: ARQ-1812 > URL: https://issues.jboss.org/browse/ARQ-1812 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - REST > Affects Versions: rest_1.0.0.Alpha2 > Reporter: Aslak Knutsen > Assignee: Bernard Labno > Fix For: rest_1.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 17:40:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 17:40:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1813) REST TestSuite has execution order issues In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1813: ---------------------------------- Summary: REST TestSuite has execution order issues Key: ARQ-1813 URL: https://issues.jboss.org/browse/ARQ-1813 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - REST Reporter: Aslak Knutsen Assignee: Bernard Labno Fix For: rest_1.0.0.Alpha3 Depending on the @Test method execution order the REST test suite randomly fail. This seems to effect all ftests and local tests, RestClientTestCase. If the ban* @Test methods are executed first, everything is ok. The banX methods will call findAllCustomers on CustomerResourceImpl and if it's the first call create Customer with id (nextId()) 1 and 2 which the Test Case is trying to lookup. If on the other hand some of the following @Test methods run first, createCustomerBareResource, manualClassModifier, nextId() is invoked and when banX methods are called later and the 'customer list' is created, the expected Customers now have id 3-4. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 17:50:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 17:50:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1813) REST TestSuite has execution order issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1813: ------------------------------- Fix Version/s: rest_1.0.0.next (was: rest_1.0.0.Alpha3) > REST TestSuite has execution order issues > ----------------------------------------- > > Key: ARQ-1813 > URL: https://issues.jboss.org/browse/ARQ-1813 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - REST > Reporter: Aslak Knutsen > Assignee: Bernard Labno > Fix For: rest_1.0.0.next > > > Depending on the @Test method execution order the REST test suite randomly fail. > This seems to effect all ftests and local tests, RestClientTestCase. > If the ban* @Test methods are executed first, everything is ok. The banX methods will call findAllCustomers on CustomerResourceImpl and if it's the first call create Customer with id (nextId()) 1 and 2 which the Test Case is trying to lookup. > If on the other hand some of the following @Test methods run first, createCustomerBareResource, manualClassModifier, nextId() is invoked and when banX methods are called later and the 'customer list' is created, the expected Customers now have id 3-4. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 18:45:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 1 Jul 2014 18:45:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1813) REST TestSuite has execution order issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981210#comment-12981210 ] Aslak Knutsen commented on ARQ-1813: ------------------------------------ Created temp fix to allow Alpha3 release to go through; https://github.com/arquillian/arquillian-extension-rest/commit/c9146cc4a82a6634a0a01110a7f76f67e7285c5a > REST TestSuite has execution order issues > ----------------------------------------- > > Key: ARQ-1813 > URL: https://issues.jboss.org/browse/ARQ-1813 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - REST > Reporter: Aslak Knutsen > Assignee: Bernard Labno > Fix For: rest_1.0.0.next > > > Depending on the @Test method execution order the REST test suite randomly fail. > This seems to effect all ftests and local tests, RestClientTestCase. > If the ban* @Test methods are executed first, everything is ok. The banX methods will call findAllCustomers on CustomerResourceImpl and if it's the first call create Customer with id (nextId()) 1 and 2 which the Test Case is trying to lookup. > If on the other hand some of the following @Test methods run first, createCustomerBareResource, manualClassModifier, nextId() is invoked and when banX methods are called later and the 'customer list' is created, the expected Customers now have id 3-4. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 04:59:25 2014 From: issues at jboss.org (Bernard Labno (JIRA)) Date: Wed, 2 Jul 2014 04:59:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1813) REST TestSuite has execution order issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernard Labno resolved ARQ-1813. -------------------------------- Resolution: Done Resolved in 52a5a6b3d34ab599090f15f4f5a3ddd82066aaf1 > REST TestSuite has execution order issues > ----------------------------------------- > > Key: ARQ-1813 > URL: https://issues.jboss.org/browse/ARQ-1813 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - REST > Reporter: Aslak Knutsen > Assignee: Bernard Labno > Fix For: rest_1.0.0.next > > > Depending on the @Test method execution order the REST test suite randomly fail. > This seems to effect all ftests and local tests, RestClientTestCase. > If the ban* @Test methods are executed first, everything is ok. The banX methods will call findAllCustomers on CustomerResourceImpl and if it's the first call create Customer with id (nextId()) 1 and 2 which the Test Case is trying to lookup. > If on the other hand some of the following @Test methods run first, createCustomerBareResource, manualClassModifier, nextId() is invoked and when banX methods are called later and the 'customer list' is created, the expected Customers now have id 3-4. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 05:17:25 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Wed, 2 Jul 2014 05:17:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981299#comment-12981299 ] Juergen Zimmermann commented on ARQGRA-454: ------------------------------------------- [~jhuska] Hello Juraj, I'm booked out this week. I'll try to provide a testcase till the end of next week. > NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final > -------------------------------------------------------------- > > Key: ARQGRA-454 > URL: https://issues.jboss.org/browse/ARQGRA-454 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juergen Zimmermann > > I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final. > The stacktrace: > {code} > org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException: > Error while initializing: class de.shop.util.IndexPage > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125) > at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120) > at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291) > at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54) > 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.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267) > 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: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:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155) > 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: java.lang.NullPointerException > at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73) > at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97) > at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76) > ... 34 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:05:24 2014 From: issues at jboss.org (Stephen Coy (JIRA)) Date: Fri, 4 Jul 2014 00:05:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982246#comment-12982246 ] Stephen Coy commented on ARQ-600: --------------------------------- I've just had a go at adding tomcat-managed-8 to this source base. And now I can see that the remaining code in tomcat-managed-5.5 and tomcat-managed-6 is effectively identical - they both use "Servlet 2.5" protocol. tomcat-managed-7 and tomcat-managed-8 both use "Servlet 3.0" protocol and use the same (overridden) deploy/undeploy/list commands. ie. There's only two different flavours of tomcat-managed-N arquillian container integrations: * 5.5 and 6 * 7 and 8 I'm thinking of moving all the java code into tomcat-managed-common and just leaving the unit tests in the tomcat-managed-N modules and building tomcat-managed-N.jars that just contain the appropriate org.jboss.arquillian.core.spi.LoadableExtension file. What do you think? > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 07:39:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 4 Jul 2014 07:39:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982343#comment-12982343 ] Aslak Knutsen commented on ARQ-600: ----------------------------------- Yeah, no need to duplicate code around. So, Sounds good. :) > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 19:22:24 2014 From: issues at jboss.org (Samuel Santos (JIRA)) Date: Sat, 5 Jul 2014 19:22:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1321) Support for HTTPS in URLs injected with @ArquillianResource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samuel Santos updated ARQ-1321: ------------------------------- Comment: was deleted (was: Hi [~smikloso], I've already implemented this locally on Arquillian Core. I'm just waiting for [~aslak] feedback for pushing it upstream.) > Support for HTTPS in URLs injected with @ArquillianResource > ----------------------------------------------------------- > > Key: ARQ-1321 > URL: https://issues.jboss.org/browse/ARQ-1321 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Samuel Santos > Assignee: Samuel Santos > > When injecting an URL like the following: > {code:java} > @ArquillianResource URL url; > {code} > HTTP protocol will always be used. This happens because "http" is hard-coded in {{URLResourceProvider}}. > Vineet Reynolds suggested that we can create the type {{SecureUrl}} and a {{SecureUrlResourceProvider}} to allow us to use HTTPS: > {code:java} > @ArquillianResource SecureUrl url; > {code} > Any comment? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 10:12:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 10:12:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) Tomcat containers should not require CATALINA_BASE In-Reply-To: References: Message-ID: Brett Meyer created ARQ-1814: -------------------------------- Summary: Tomcat containers should not require CATALINA_BASE Key: ARQ-1814 URL: https://issues.jboss.org/browse/ARQ-1814 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: tomcat_1.0.0.CR7 Reporter: Brett Meyer CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. {quote} org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) Caused by: java.lang.NullPointerException at java.io.File.(File.java:251) at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) ... 67 more {quote} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 10:12:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 10:12:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) Tomcat containers should not require CATALINA_BASE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARQ-1814: ----------------------------- Description: CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. {code} org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) Caused by: java.lang.NullPointerException at java.io.File.(File.java:251) at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) ... 67 more {code} was: CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. {quote} org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) Caused by: java.lang.NullPointerException at java.io.File.(File.java:251) at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) ... 67 more {quote} > Tomcat containers should not require CATALINA_BASE > -------------------------------------------------- > > Key: ARQ-1814 > URL: https://issues.jboss.org/browse/ARQ-1814 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Brett Meyer > > CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. > When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:251) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 10:12:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 10:12:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) Tomcat containers should not require CATALINA_BASE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982481#comment-12982481 ] Brett Meyer commented on ARQ-1814: ---------------------------------- Or, at least document it in https://docs.jboss.org/author/display/ARQ/Tomcat+7.0+-+Managed > Tomcat containers should not require CATALINA_BASE > -------------------------------------------------- > > Key: ARQ-1814 > URL: https://issues.jboss.org/browse/ARQ-1814 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Brett Meyer > > CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. > When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:251) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 14:26:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 14:26:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) Tomcat containers should not require CATALINA_BASE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982486#comment-12982486 ] Brett Meyer commented on ARQ-1814: ---------------------------------- I turns out the following is simply too early within TomcatManagedConfiguration. In the constructor, it only considers the CATALINA_HOME/CATALINA_BASE env vars. If you instead use , CATALINA_HOME can be left null and therefore catalinaBase is never corrected. The check needs to be delayed until #getCatalinaBase. {code} if (catalinaBase == null || "".equals(catalinaBase)) { catalinaBase = catalinaHome; } {code} Is something else calling > Tomcat containers should not require CATALINA_BASE > -------------------------------------------------- > > Key: ARQ-1814 > URL: https://issues.jboss.org/browse/ARQ-1814 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Brett Meyer > > CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. > When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:251) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 14:26:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 14:26:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) Tomcat containers should not require CATALINA_BASE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982486#comment-12982486 ] Brett Meyer edited comment on ARQ-1814 at 7/6/14 2:25 PM: ---------------------------------------------------------- I turns out the following is simply too early within TomcatManagedConfiguration. In the constructor, it only considers the CATALINA_HOME/CATALINA_BASE env vars. If you instead use , CATALINA_HOME can be left null and therefore catalinaBase is never corrected. The check needs to be delayed until #getCatalinaBase. {code} if (catalinaBase == null || "".equals(catalinaBase)) { catalinaBase = catalinaHome; } {code} was (Author: brmeyer): I turns out the following is simply too early within TomcatManagedConfiguration. In the constructor, it only considers the CATALINA_HOME/CATALINA_BASE env vars. If you instead use , CATALINA_HOME can be left null and therefore catalinaBase is never corrected. The check needs to be delayed until #getCatalinaBase. {code} if (catalinaBase == null || "".equals(catalinaBase)) { catalinaBase = catalinaHome; } {code} Is something else calling > Tomcat containers should not require CATALINA_BASE > -------------------------------------------------- > > Key: ARQ-1814 > URL: https://issues.jboss.org/browse/ARQ-1814 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Brett Meyer > > CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. > When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:251) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 14:26:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 14:26:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) TomcatManagedConfiguration validates catalinaBase too soon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARQ-1814: ----------------------------- Summary: TomcatManagedConfiguration validates catalinaBase too soon (was: Tomcat containers should not require CATALINA_BASE) > TomcatManagedConfiguration validates catalinaBase too soon > ---------------------------------------------------------- > > Key: ARQ-1814 > URL: https://issues.jboss.org/browse/ARQ-1814 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Brett Meyer > > CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. > When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:251) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 14:28:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 14:28:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) TomcatManagedConfiguration validates catalinaBase too soon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARQ-1814: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-tomcat/pull/26 Pull request: https://github.com/arquillian/arquillian-container-tomcat/pull/26 > TomcatManagedConfiguration validates catalinaBase too soon > ---------------------------------------------------------- > > Key: ARQ-1814 > URL: https://issues.jboss.org/browse/ARQ-1814 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Brett Meyer > > CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. > When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:251) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:08:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 7 Jul 2014 17:08:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-600) Improve Tomcat codebase - Managed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-600: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done pushed upstream https://github.com/arquillian/arquillian-container-tomcat/commit/8a91b97171a2a822db9f5c6ae196b5e9ad7e00ac > Improve Tomcat codebase - Managed > --------------------------------- > > Key: ARQ-600 > URL: https://issues.jboss.org/browse/ARQ-600 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Aslak Knutsen > Assignee: Stephen Coy > Fix For: tomcat_1.0.0.Final > > > After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration. > We can create a similar tomcat-common-managed that will have the common parts between the different versions. > {note} > If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions? > {note} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:10:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 7 Jul 2014 17:10:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1814) TomcatManagedConfiguration validates catalinaBase too soon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1814: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: tomcat_1.0.0.Final Resolution: Done pushed upstream; https://github.com/arquillian/arquillian-container-tomcat/commit/b44ff17a4906b0653f4bbe182c49c4f946007af5 > TomcatManagedConfiguration validates catalinaBase too soon > ---------------------------------------------------------- > > Key: ARQ-1814 > URL: https://issues.jboss.org/browse/ARQ-1814 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: tomcat_1.0.0.CR7 > Reporter: Brett Meyer > Fix For: tomcat_1.0.0.Final > > > CATALINA_BASE is only necessary if you're running multiple instances of Tomcat on a single host. If only one instance is running, CATALINA_BASE==CATALINA_HOME. > When catalinaBase is not set in arquillian.xml (tomcat 7 managed container), you get the following NPE. TomcatManagedContainer could probably assume CATALINA_BASE==CATALINA_HOME if CATALINA_BASE is not explicitly set. > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:177) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:251) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:105) > ... 67 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 18:43:35 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Mon, 7 Jul 2014 18:43:35 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982821#comment-12982821 ] Karthik Shantaraman commented on ARQ-197: ----------------------------------------- Hi, Is there a way to run multiple tests with a single Deployment? > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 18:43:41 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Mon, 7 Jul 2014 18:43:41 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-567) Supporting Test Suites (@ArquillianSuite) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982822#comment-12982822 ] Karthik Shantaraman commented on ARQ-567: ----------------------------------------- Hi, Is there a way to run multiple tests with a single Deployment? > Supporting Test Suites (@ArquillianSuite) > ----------------------------------------- > > Key: ARQ-567 > URL: https://issues.jboss.org/browse/ARQ-567 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mousavi Jahan Abadi S. M. > > Currently, it is supported that JUnit test cases being run by Arquillian. This feature request is request for supporting test suites too to be run by Arquillian too. Idea is like: > @RunWith(ArquillianSuite.class) > @Suite.SuiteClasses( { TestCase1.class, TestCase2.class, .... } ) > public class AllTests{ > @Deployment > public static JavaArchive createTestArchive(){ > return ShrinkWrap.create(JavaArchive.class,"test.jar"); > } > } > The advantages of above approach for users of Arquillian framework are: > - Test cases don't needed to be modified to have: "@RunWith(Arquillian.class)" annotation. In other words, test cases will be pure JUnit code, and no Arquillian code (results in less coding for end users). > - It is not necessary to include the static "@Deployment" methods in all test cases any more, and only Test Suite need to define the archieving/deployment related setting/definitions. > The advantage of above approach for framework itself is: > - From performance point-of-view, it becomes possible for Arquillian to deploy all test cases in the Test Suite into J2EE container in one action (one deploy/undeploy for one test suite, instead of mulitple deploy/undeploy for each test case). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 20:57:32 2014 From: issues at jboss.org (MINNA HU (JIRA)) Date: Mon, 7 Jul 2014 20:57:32 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982833#comment-12982833 ] MINNA HU commented on ARQ-197: ------------------------------ [~kshantaraman]: try https://github.com/ingwarsw/arquillian-suite-extension, it works for me. Our full deployment will take 10 minutes to run, and we have 8 test classes right now, so at least arquillian-suite-extension saves us 7*10 minutes when it reuses the deployment for each test class. We will have more test classes in future, the improvement is dramatic. > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 13:46:36 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Tue, 8 Jul 2014 13:46:36 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983259#comment-12983259 ] Karthik Shantaraman commented on ARQ-197: ----------------------------------------- Hi [~huangdihu]], I have gone through that plugin and now am left with a couple of questions 1) Does each of my tests need to be in their own class? 2) Does the Deployment class have to be separate? 3) Does the plugin work Test Suites TESTNG tests? Thanks, Karthik > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 13:46:47 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Tue, 8 Jul 2014 13:46:47 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983259#comment-12983259 ] Karthik Shantaraman edited comment on ARQ-197 at 7/8/14 1:46 PM: ----------------------------------------------------------------- Hi [~huangdihu], I have gone through that plugin and now am left with a couple of questions 1) Does each of my tests need to be in their own class? 2) Does the Deployment class have to be separate? 3) Does the plugin work Test Suites TESTNG tests? Thanks, Karthik was (Author: kshantaraman): Hi [~huangdihu]], I have gone through that plugin and now am left with a couple of questions 1) Does each of my tests need to be in their own class? 2) Does the Deployment class have to be separate? 3) Does the plugin work Test Suites TESTNG tests? Thanks, Karthik > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 16:42:35 2014 From: issues at jboss.org (MINNA HU (JIRA)) Date: Tue, 8 Jul 2014 16:42:35 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983299#comment-12983299 ] MINNA HU commented on ARQ-197: ------------------------------ Hi [~kshantaraman], I am not the developer of arquillian-suite-extension, but I would like to answer your questions as I like this extension, and I'd like to promote it to more people, thank you~ Please see my comments inline. 1) Does each of my tests need to be in their own class? The extension does not affect the way of organizing your tests, for me, I have several test classes, and each test class contain several tests for each feature. 2) Does the Deployment class have to be separate? Yes, I created a separate class for deployments, and mark it as @ArquillianSuiteDeployment. 3) Does the plugin work Test Suites TESTNG tests? Yes, I am using TestNG tests. > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 11:33:25 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Thu, 10 Jul 2014 11:33:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1815) Unable to locate Oracle Statement filter In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-1815: ----------------------------------- Summary: Unable to locate Oracle Statement filter Key: ARQ-1815 URL: https://issues.jboss.org/browse/ARQ-1815 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha7 Reporter: Bartosz Majsak Assignee: Bartosz Majsak Priority: Blocker Fix For: persistence_1.0.0.Alpha7 When trying to define custom table filter using {{org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider}} It's resulting in {{Unable to find sequence filter for org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider. Using default database sequence filter.}} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 11:35:24 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Thu, 10 Jul 2014 11:35:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1815) Unable to locate Oracle Sequence filter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1815: -------------------------------- Summary: Unable to locate Oracle Sequence filter (was: Unable to locate Oracle Statement filter) > Unable to locate Oracle Sequence filter > --------------------------------------- > > Key: ARQ-1815 > URL: https://issues.jboss.org/browse/ARQ-1815 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Priority: Blocker > Fix For: persistence_1.0.0.Alpha7 > > > When trying to define custom table filter using > {{org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider}} > It's resulting in > {{Unable to find sequence filter for org.jboss.arquillian.persistence.dbunit.filter.OracleDatabaseSequenceFilterProvider. Using default database sequence filter.}} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 15:26:35 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Thu, 10 Jul 2014 15:26:35 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984042#comment-12984042 ] Karthik Shantaraman commented on ARQ-197: ----------------------------------------- Hi [~huangdihu], Thank you so much for taking your time to reply to my questions patiently. I currently have a project that has a deployment class with the extension added and two test classes. How do I run this project to check whether the deployment happens only once? > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 15:34:35 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Thu, 10 Jul 2014 15:34:35 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984042#comment-12984042 ] Karthik Shantaraman edited comment on ARQ-197 at 7/10/14 3:33 PM: ------------------------------------------------------------------ Hi [~huangdihu], Thank you so much for taking your time to reply to my questions patiently. I currently have a project that has a deployment class Deployments with the extension @ArquillianSuiteDeployment added and two test classes Greeter and Greeter2 both JUnit Tests Running the Tests gives an exception and tests fail. Could you let me know what I am missing in the Test Classes? Or is it possible to provide ur mail ID so that I could send a snippet of my classes? was (Author: kshantaraman): Hi [~huangdihu], Thank you so much for taking your time to reply to my questions patiently. I currently have a project that has a deployment class with the extension added and two test classes. How do I run this project to check whether the deployment happens only once? > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 15:59:34 2014 From: issues at jboss.org (MINNA HU (JIRA)) Date: Thu, 10 Jul 2014 15:59:34 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984052#comment-12984052 ] MINNA HU commented on ARQ-197: ------------------------------ Hi [~kshantaraman], You can post your questions under https://github.com/ingwarsw/arquillian-suite-extension/issues, and the community can answer you, thank you~ > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 03:56:24 2014 From: issues at jboss.org (Peter Probst (JIRA)) Date: Fri, 11 Jul 2014 03:56:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1816) Arquillian core is eating up framework exceptions In-Reply-To: References: Message-ID: Peter Probst created ARQ-1816: --------------------------------- Summary: Arquillian core is eating up framework exceptions Key: ARQ-1816 URL: https://issues.jboss.org/browse/ARQ-1816 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.1.4.Final Environment: wildfly 8.1.0.Final, arq bom 1.1.4.Final, persistence extension 1.0.0.Alpha7, shrinkwrap resolver bom 2.1.1 (and arquillian-suite-extension 1.1.1) Reporter: Peter Probst using arquillian-suite-extension with arquillian-persistence-extension i found that arquillian is eating up severe exceptions. The test runner reports success on all tests - but non of the tests are running correctly. I have created a maven example project for arquillian-suite-extension to show the problem, that the suite extension is not working correctly with the persistence extension. This sample project can be used to reproduce also the exception handling problem. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 04:02:24 2014 From: issues at jboss.org (Peter Probst (JIRA)) Date: Fri, 11 Jul 2014 04:02:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1816) Arquillian core is eating up framework exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984135#comment-12984135 ] Peter Probst commented on ARQ-1816: ----------------------------------- Also in the case, when inserting table data with dbUnit and there are problems in the test data (e.g. data too long for column) the exceptions are lost in the framework... > Arquillian core is eating up framework exceptions > ------------------------------------------------- > > Key: ARQ-1816 > URL: https://issues.jboss.org/browse/ARQ-1816 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.4.Final > Environment: wildfly 8.1.0.Final, arq bom 1.1.4.Final, persistence extension 1.0.0.Alpha7, shrinkwrap resolver bom 2.1.1 (and arquillian-suite-extension 1.1.1) > Reporter: Peter Probst > > using arquillian-suite-extension with arquillian-persistence-extension i found that arquillian is eating up severe exceptions. The test runner reports success on all tests - but non of the tests are running correctly. I have created a maven example project for arquillian-suite-extension to show the problem, that the suite extension is not working correctly with the persistence extension. This sample project can be used to reproduce also the exception handling problem. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 09:46:27 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 11 Jul 2014 09:46:27 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1309) Persistence extension does not work with Jacoco extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak reopened ARQ-1309: --------------------------------- > Persistence extension does not work with Jacoco extension > --------------------------------------------------------- > > Key: ARQ-1309 > URL: https://issues.jboss.org/browse/ARQ-1309 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: 1.0.0.Alpha5 > Reporter: Peter Schonhofen > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When the Jacoco and persistence extension is used together in a project, a "PersistenceExtensionInitializationException: Unable to create persistence configuration" is thrown. > The cause of the exception is that in the ConfigurationImporter class the createConfiguration method receives a fieldsWithValues map with a "$jacocoData" item in it. Because the method cannot process this item, it fails. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 09:46:28 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 11 Jul 2014 09:46:28 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1309) Persistence extension does not work with Jacoco extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1309: -------------------------------- Fix Version/s: persistence_1.0.0.next (was: persistence_1.0.0.Alpha7) > Persistence extension does not work with Jacoco extension > --------------------------------------------------------- > > Key: ARQ-1309 > URL: https://issues.jboss.org/browse/ARQ-1309 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: 1.0.0.Alpha5 > Reporter: Peter Schonhofen > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > When the Jacoco and persistence extension is used together in a project, a "PersistenceExtensionInitializationException: Unable to create persistence configuration" is thrown. > The cause of the exception is that in the ConfigurationImporter class the createConfiguration method receives a fieldsWithValues map with a "$jacocoData" item in it. Because the method cannot process this item, it fails. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 09:54:25 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 11 Jul 2014 09:54:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1309) Persistence extension does not work with Jacoco extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1309: -------------------------------- Forum Reference: https://community.jboss.org/thread/165825 > Persistence extension does not work with Jacoco extension > --------------------------------------------------------- > > Key: ARQ-1309 > URL: https://issues.jboss.org/browse/ARQ-1309 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: 1.0.0.Alpha5 > Reporter: Peter Schonhofen > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > When the Jacoco and persistence extension is used together in a project, a "PersistenceExtensionInitializationException: Unable to create persistence configuration" is thrown. > The cause of the exception is that in the ConfigurationImporter class the createConfiguration method receives a fieldsWithValues map with a "$jacocoData" item in it. Because the method cannot process this item, it fails. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 09:54:27 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 11 Jul 2014 09:54:27 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1309) Persistence extension does not work with Jacoco extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1309: -------------------------------- Forum Reference: https://community.jboss.org/thread/165825, https://community.jboss.org/message/876565 (was: https://community.jboss.org/thread/165825) > Persistence extension does not work with Jacoco extension > --------------------------------------------------------- > > Key: ARQ-1309 > URL: https://issues.jboss.org/browse/ARQ-1309 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: 1.0.0.Alpha5 > Reporter: Peter Schonhofen > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > When the Jacoco and persistence extension is used together in a project, a "PersistenceExtensionInitializationException: Unable to create persistence configuration" is thrown. > The cause of the exception is that in the ConfigurationImporter class the createConfiguration method receives a fieldsWithValues map with a "$jacocoData" item in it. Because the method cannot process this item, it fails. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 09:56:26 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 11 Jul 2014 09:56:26 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1309) Persistence extension does not work with Jacoco extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1309: -------------------------------- Forum Reference: https://community.jboss.org/thread/165825, https://community.jboss.org/message/876565, https://community.jboss.org/thread/241717 (was: https://community.jboss.org/thread/165825, https://community.jboss.org/message/876565) > Persistence extension does not work with Jacoco extension > --------------------------------------------------------- > > Key: ARQ-1309 > URL: https://issues.jboss.org/browse/ARQ-1309 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: 1.0.0.Alpha5 > Reporter: Peter Schonhofen > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > When the Jacoco and persistence extension is used together in a project, a "PersistenceExtensionInitializationException: Unable to create persistence configuration" is thrown. > The cause of the exception is that in the ConfigurationImporter class the createConfiguration method receives a fieldsWithValues map with a "$jacocoData" item in it. Because the method cannot process this item, it fails. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 10:21:25 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 11 Jul 2014 10:21:25 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1817) Ad-hoc H2 java functions are treated as comments In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-1817: ----------------------------------- Summary: Ad-hoc H2 java functions are treated as comments Key: ARQ-1817 URL: https://issues.jboss.org/browse/ARQ-1817 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha7 Reporter: Bartosz Majsak Assignee: Bartosz Majsak -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 10:27:26 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 11 Jul 2014 10:27:26 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1817) Ad-hoc H2 java functions are treated as comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1817: -------------------------------- Fix Version/s: persistence_1.0.0.next > Ad-hoc H2 java functions are treated as comments > ------------------------------------------------ > > Key: ARQ-1817 > URL: https://issues.jboss.org/browse/ARQ-1817 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 12:06:24 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 11 Jul 2014 12:06:24 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1816) Arquillian core is eating up framework exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984349#comment-12984349 ] Aslak Knutsen commented on ARQ-1816: ------------------------------------ How about 1.1.5.Final? > Arquillian core is eating up framework exceptions > ------------------------------------------------- > > Key: ARQ-1816 > URL: https://issues.jboss.org/browse/ARQ-1816 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.4.Final > Environment: wildfly 8.1.0.Final, arq bom 1.1.4.Final, persistence extension 1.0.0.Alpha7, shrinkwrap resolver bom 2.1.1 (and arquillian-suite-extension 1.1.1) > Reporter: Peter Probst > > using arquillian-suite-extension with arquillian-persistence-extension i found that arquillian is eating up severe exceptions. The test runner reports success on all tests - but non of the tests are running correctly. I have created a maven example project for arquillian-suite-extension to show the problem, that the suite extension is not working correctly with the persistence extension. This sample project can be used to reproduce also the exception handling problem. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 03:24:29 2014 From: issues at jboss.org (Peter Probst (JIRA)) Date: Mon, 14 Jul 2014 03:24:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1816) Arquillian core is eating up framework exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984560#comment-12984560 ] Peter Probst commented on ARQ-1816: ----------------------------------- Hi Aslak, i will check... > Arquillian core is eating up framework exceptions > ------------------------------------------------- > > Key: ARQ-1816 > URL: https://issues.jboss.org/browse/ARQ-1816 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.4.Final > Environment: wildfly 8.1.0.Final, arq bom 1.1.4.Final, persistence extension 1.0.0.Alpha7, shrinkwrap resolver bom 2.1.1 (and arquillian-suite-extension 1.1.1) > Reporter: Peter Probst > > using arquillian-suite-extension with arquillian-persistence-extension i found that arquillian is eating up severe exceptions. The test runner reports success on all tests - but non of the tests are running correctly. I have created a maven example project for arquillian-suite-extension to show the problem, that the suite extension is not working correctly with the persistence extension. This sample project can be used to reproduce also the exception handling problem. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 03:36:30 2014 From: issues at jboss.org (Peter Probst (JIRA)) Date: Mon, 14 Jul 2014 03:36:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1816) Arquillian core is eating up framework exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Probst resolved ARQ-1816. ------------------------------- Fix Version/s: 1.1.5.Final Resolution: Done Thanks Aslak for pinpointing. Version 1.1.5.Final fixes the problem. > Arquillian core is eating up framework exceptions > ------------------------------------------------- > > Key: ARQ-1816 > URL: https://issues.jboss.org/browse/ARQ-1816 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.1.4.Final > Environment: wildfly 8.1.0.Final, arq bom 1.1.4.Final, persistence extension 1.0.0.Alpha7, shrinkwrap resolver bom 2.1.1 (and arquillian-suite-extension 1.1.1) > Reporter: Peter Probst > Fix For: 1.1.5.Final > > > using arquillian-suite-extension with arquillian-persistence-extension i found that arquillian is eating up severe exceptions. The test runner reports success on all tests - but non of the tests are running correctly. I have created a maven example project for arquillian-suite-extension to show the problem, that the suite extension is not working correctly with the persistence extension. This sample project can be used to reproduce also the exception handling problem. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:52:30 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 14 Jul 2014 09:52:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1818: ---------------------------------- Summary: JUnit @Before/After phase is called after/before Arquillian's Before/After phase Key: ARQ-1818 URL: https://issues.jboss.org/browse/ARQ-1818 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Harness Integration Affects Versions: 1.1.5.Final Reporter: Aslak Knutsen In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:52:31 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 14 Jul 2014 09:52:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1818: ------------------------------- Forum Reference: https://community.jboss.org/thread/242571 > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Aslak Knutsen > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:54:29 2014 From: issues at jboss.org (SBS JIRA Integration (JIRA)) Date: Mon, 14 Jul 2014 09:54:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SBS JIRA Integration updated ARQ-1818: -------------------------------------- Forum Reference: https://community.jboss.org/thread/242571, https://community.jboss.org/message/880399#880399 (was: https://community.jboss.org/thread/242571) > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Aslak Knutsen > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:54:29 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 14 Jul 2014 09:54:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1818: ------------------------------- Priority: Critical (was: Major) > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 1.1.6.Final > > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:54:29 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 14 Jul 2014 09:54:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1818: ------------------------------- Fix Version/s: 1.1.6.Final > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Aslak Knutsen > Fix For: 1.1.6.Final > > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:54:30 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 14 Jul 2014 09:54:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen reassigned ARQ-1818: ---------------------------------- Assignee: Aslak Knutsen > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Priority: Blocker > Fix For: 1.1.6.Final > > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:54:30 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 14 Jul 2014 09:54:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1818) JUnit @Before/After phase is called after/before Arquillian's Before/After phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1818: ------------------------------- Priority: Blocker (was: Critical) > JUnit @Before/After phase is called after/before Arquillian's Before/After phase > -------------------------------------------------------------------------------- > > Key: ARQ-1818 > URL: https://issues.jboss.org/browse/ARQ-1818 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Harness Integration > Affects Versions: 1.1.5.Final > Reporter: Aslak Knutsen > Priority: Blocker > Fix For: 1.1.6.Final > > > In < 1.1.5.Final JUnit's @Before and @After was called by Arquillian as part of Arquillian's Before and After phases. This changed by accident during the JUnit Rule support rewrite and @Before is now called after Arquillian's Before and @After phase is now called Before Arquillian's After. > This break down APIs like Deployer/ContainerController as non of the Suite/Class/Test Contexts are active at that point. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 19:44:48 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Mon, 14 Jul 2014 19:44:48 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984943#comment-12984943 ] Karthik Shantaraman commented on ARQ-197: ----------------------------------------- Hi [~huangdihu] That was really helpful. Thank you for the link. Is it possible to use ArquillianSuiteExtension in Apache Tomcat Container? > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 19:44:56 2014 From: issues at jboss.org (Karthik Shantaraman (JIRA)) Date: Mon, 14 Jul 2014 19:44:56 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984943#comment-12984943 ] Karthik Shantaraman edited comment on ARQ-197 at 7/14/14 7:43 PM: ------------------------------------------------------------------ Hi [~huangdihu] That was really helpful. Thank you for the link. Is it possible to use ArquillianSuiteExtension in Arquillian with JUnit tests running in Apache Tomcat Container? was (Author: kshantaraman): Hi [~huangdihu] That was really helpful. Thank you for the link. Is it possible to use ArquillianSuiteExtension in Apache Tomcat Container? > Research support for @Deployment on multiple levels > --------------------------------------------------- > > Key: ARQ-197 > URL: https://issues.jboss.org/browse/ARQ-197 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Reporter: Aslak Knutsen > Priority: Critical > Fix For: 2.0.0.CR1 > > > One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 07:54:29 2014 From: issues at jboss.org (Raj Haque (JIRA)) Date: Tue, 15 Jul 2014 07:54:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1819) CDI not working in Jboss as 7.1 In-Reply-To: References: Message-ID: Raj Haque created ARQ-1819: ------------------------------ Summary: CDI not working in Jboss as 7.1 Key: ARQ-1819 URL: https://issues.jboss.org/browse/ARQ-1819 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Raj Haque Priority: Critical Hi Guys, I am having problems in Arquillian CDI. I am using in my parent pom.... org.jboss.arquillian.junit arquillian-junit-container 1.0.0.CR7 test My Arquillian.xml is like this /SDDevelopmentMVN/TEST_temp REMOTE /SDDevelopmentMVN/jboss/jbossInternalMVN 127.0.0.1 10099 ------------------------- My Test class is @RunWith(Arquillian.class) @RunAsClient public class PayrollCRUDServiceRestfullTest { @Deployment public static Archive createTestArchive() { return ShrinkWrap.create(WebArchive.class, "test1177.war") .addClasses(MiscUtilsSD.class,GenericAuditService.class,PayrollCRUDService.class, SmartDAO.class,Resources.class) .addPackage("com.animation2000.coreservices.domain") .addPackage("com.animation2000.coreservices.audit.domain") .addPackage("com.animation2000.coreservices.audit.service") .addPackage("com.animation2000.coreservices.audit.wrapper") .addPackage("com.animation2000.coreservices.domain.customized") .addPackage("com.animation2000.smart.dao") .addPackage("com.animation2000.coreservices.payroll.crud.service") .addAsResource("META-INF/persistence.xml", "META-INF/persistence.xml") .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); } @Inject PayrollCRUDService payrollCRUDService; But payrollCRUDService is null.. Any advise?Please. Many Thanks -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:10:30 2014 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Tue, 15 Jul 2014 09:10:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985177#comment-12985177 ] Rafael Pestano commented on ARQ-1444: ------------------------------------- Hi guys, is this issue really resolved? im trying to clean a oracle db using @CleanupUsingScript or @ApplyScriptAfter/Before and still having ORA-00911: invalid character in Alpha. My scripts are simple DELETE from TABLE; my arquillian.xml is as follows: TR_DETRAN_RED_AD true java:jboss/datasources/RedTesteDS false thanks in advance. > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:12:31 2014 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Tue, 15 Jul 2014 09:12:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985179#comment-12985179 ] Rafael Pestano commented on ARQ-1444: ------------------------------------- * in Alpha7 > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:26:37 2014 From: issues at jboss.org (Michel Graciano (JIRA)) Date: Tue, 15 Jul 2014 09:26:37 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985189#comment-12985189 ] Michel Graciano commented on ARQ-1444: -------------------------------------- Rafael, there is a gotcha here. Try add the property sqlDialect at your arquillian.xml as follow: {code:xml} oracle {code} The defualt delimiter is already ; so it is not necessary to define it. I solved a similar issue doing this in my tests. > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:48:30 2014 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Tue, 15 Jul 2014 09:48:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985207#comment-12985207 ] Rafael Pestano commented on ARQ-1444: ------------------------------------- bingo! that was the issue, thanks Michel. maybe we should add that in docs: https://docs.jboss.org/author/display/ARQ/Persistence > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:48:30 2014 From: issues at jboss.org (Raj Haque (JIRA)) Date: Tue, 15 Jul 2014 09:48:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1819) CDI not working in Jboss as 7.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985208#comment-12985208 ] Raj Haque commented on ARQ-1819: -------------------------------- FIXED: for some reason I had to add all this to get it working. Not sure why? .setWebXML(new File("src/main/webapp/WEB-INF/web.xml")) .addAsResource(new File("src/main/webapp/WEB-INF/jboss-web.xml")) .addAsResource("META-INF/persistence.xml", "META-INF/persistence.xml") .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml"); > CDI not working in Jboss as 7.1 > ------------------------------- > > Key: ARQ-1819 > URL: https://issues.jboss.org/browse/ARQ-1819 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Raj Haque > Priority: Critical > > Hi Guys, I am having problems in Arquillian CDI. > I am using in my parent pom.... > > org.jboss.arquillian.junit > arquillian-junit-container > 1.0.0.CR7 > test > > My Arquillian.xml is like this > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > > > /SDDevelopmentMVN/TEST_temp > > > > > REMOTE > > > /SDDevelopmentMVN/jboss/jbossInternalMVN > 127.0.0.1 > 10099 > > > > ------------------------- > My Test class is > @RunWith(Arquillian.class) > @RunAsClient > public class PayrollCRUDServiceRestfullTest { > @Deployment > public static Archive createTestArchive() { > return ShrinkWrap.create(WebArchive.class, "test1177.war") > .addClasses(MiscUtilsSD.class,GenericAuditService.class,PayrollCRUDService.class, SmartDAO.class,Resources.class) > .addPackage("com.animation2000.coreservices.domain") > .addPackage("com.animation2000.coreservices.audit.domain") > .addPackage("com.animation2000.coreservices.audit.service") > .addPackage("com.animation2000.coreservices.audit.wrapper") > .addPackage("com.animation2000.coreservices.domain.customized") > > .addPackage("com.animation2000.smart.dao") > .addPackage("com.animation2000.coreservices.payroll.crud.service") > .addAsResource("META-INF/persistence.xml", "META-INF/persistence.xml") > > .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); > > } > @Inject > PayrollCRUDService payrollCRUDService; > But payrollCRUDService is null.. > Any advise?Please. > Many Thanks -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:48:31 2014 From: issues at jboss.org (Raj Haque (JIRA)) Date: Tue, 15 Jul 2014 09:48:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1819) CDI not working in Jboss as 7.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raj Haque resolved ARQ-1819. ---------------------------- Resolution: Done > CDI not working in Jboss as 7.1 > ------------------------------- > > Key: ARQ-1819 > URL: https://issues.jboss.org/browse/ARQ-1819 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Raj Haque > Priority: Critical > > Hi Guys, I am having problems in Arquillian CDI. > I am using in my parent pom.... > > org.jboss.arquillian.junit > arquillian-junit-container > 1.0.0.CR7 > test > > My Arquillian.xml is like this > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > > > /SDDevelopmentMVN/TEST_temp > > > > > REMOTE > > > /SDDevelopmentMVN/jboss/jbossInternalMVN > 127.0.0.1 > 10099 > > > > ------------------------- > My Test class is > @RunWith(Arquillian.class) > @RunAsClient > public class PayrollCRUDServiceRestfullTest { > @Deployment > public static Archive createTestArchive() { > return ShrinkWrap.create(WebArchive.class, "test1177.war") > .addClasses(MiscUtilsSD.class,GenericAuditService.class,PayrollCRUDService.class, SmartDAO.class,Resources.class) > .addPackage("com.animation2000.coreservices.domain") > .addPackage("com.animation2000.coreservices.audit.domain") > .addPackage("com.animation2000.coreservices.audit.service") > .addPackage("com.animation2000.coreservices.audit.wrapper") > .addPackage("com.animation2000.coreservices.domain.customized") > > .addPackage("com.animation2000.smart.dao") > .addPackage("com.animation2000.coreservices.payroll.crud.service") > .addAsResource("META-INF/persistence.xml", "META-INF/persistence.xml") > > .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); > > } > @Inject > PayrollCRUDService payrollCRUDService; > But payrollCRUDService is null.. > Any advise?Please. > Many Thanks -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:52:30 2014 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Tue, 15 Jul 2014 09:52:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985211#comment-12985211 ] Rafael Pestano commented on ARQ-1444: ------------------------------------- sorry but the issue remains even with the sqlDialect property ;( > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:02:43 2014 From: issues at jboss.org (Michel Graciano (JIRA)) Date: Tue, 15 Jul 2014 10:02:43 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985217#comment-12985217 ] Michel Graciano commented on ARQ-1444: -------------------------------------- I will update the Reference Guide later today, but I need to get all the possible values so I will need some time to dig the source code. Maybe you have some 'cache' for your arquillian file, or some tests run with different version of this file? I think here is not the place for this discussion, maybe you can add more details in the forum reference https://community.jboss.org/message/807298#807298. Regards > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:06:35 2014 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Tue, 15 Jul 2014 10:06:35 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985221#comment-12985221 ] Rafael Pestano commented on ARQ-1444: ------------------------------------- Sure, i will do that but first i will make sure i dont have anything on my environment. thanks again. > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:08:31 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Tue, 15 Jul 2014 10:08:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985222#comment-12985222 ] Bartosz Majsak commented on ARQ-1444: ------------------------------------- No worries, I will take care of it. Basically there are only two at this moment + SPI so that you can implement your own logic. @Rafael I will have a closer look at it. > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 06:32:30 2014 From: issues at jboss.org (Miroslav Novak (JIRA)) Date: Wed, 16 Jul 2014 06:32:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian In-Reply-To: References: Message-ID: Miroslav Novak created ARQ-1820: ----------------------------------- Summary: LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian Key: ARQ-1820 URL: https://issues.jboss.org/browse/ARQ-1820 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Miroslav Novak There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: - Start two EAP 6.3.0.ER9 servers - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server - Kill -9 "first EAP server" - Producer and consumer failovers to backup Problem: When producer and consumer failovers to backup then it fails with: {code} 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) {code} Second EAP server logs: {code} 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] {code} It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader); When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? I'm assigning this to Aslak as he could know? :-) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 06:32:31 2014 From: issues at jboss.org (Miroslav Novak (JIRA)) Date: Wed, 16 Jul 2014 06:32:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miroslav Novak updated ARQ-1820: -------------------------------- Description: There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: - Start two EAP 6.3.0.ER9 servers - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server - Kill -9 "first EAP server" - Producer and consumer failovers to backup Problem: When producer and consumer failovers to backup then it fails with: {code} 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) {code} Second EAP server logs: {code} 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] {code} It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? I'm assigning this to Aslak as he could know? :-) was: There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: - Start two EAP 6.3.0.ER9 servers - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server - Kill -9 "first EAP server" - Producer and consumer failovers to backup Problem: When producer and consumer failovers to backup then it fails with: {code} 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) {code} Second EAP server logs: {code} 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] {code} It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader); When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? I'm assigning this to Aslak as he could know? :-) > LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian > ----------------------------------------------------------------------------------------------------- > > Key: ARQ-1820 > URL: https://issues.jboss.org/browse/ARQ-1820 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Miroslav Novak > > There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: > - Start two EAP 6.3.0.ER9 servers > - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) > - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server > - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server > - Kill -9 "first EAP server" > - Producer and consumer failovers to backup > Problem: > When producer and consumer failovers to backup then it fails with: > {code} > 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover > HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) > at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) > at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) > at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > Second EAP server logs: > {code} > 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > {code} > It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that > javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: > {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} > When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? > I'm assigning this to Aslak as he could know? :-) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 06:36:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 16 Jul 2014 06:36:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated ARQ-1820: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1119751 > LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian > ----------------------------------------------------------------------------------------------------- > > Key: ARQ-1820 > URL: https://issues.jboss.org/browse/ARQ-1820 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Miroslav Novak > > There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: > - Start two EAP 6.3.0.ER9 servers > - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) > - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server > - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server > - Kill -9 "first EAP server" > - Producer and consumer failovers to backup > Problem: > When producer and consumer failovers to backup then it fails with: > {code} > 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover > HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) > at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) > at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) > at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > Second EAP server logs: > {code} > 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > {code} > It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that > javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: > {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} > When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? > I'm assigning this to Aslak as he could know? :-) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 07:30:31 2014 From: issues at jboss.org (Miroslav Novak (JIRA)) Date: Wed, 16 Jul 2014 07:30:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miroslav Novak updated ARQ-1820: -------------------------------- Description: There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: - Start two EAP 6.3.0.ER9 servers - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server - Kill -9 "first EAP server" - Producer and consumer failovers to backup Problem: When producer and consumer failovers to backup then it fails with: {code} 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) {code} Second EAP server logs: {code} 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] {code} It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? was: There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: - Start two EAP 6.3.0.ER9 servers - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server - Kill -9 "first EAP server" - Producer and consumer failovers to backup Problem: When producer and consumer failovers to backup then it fails with: {code} 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) {code} Second EAP server logs: {code} 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] {code} It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? I'm assigning this to Aslak as he could know? :-) > LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian > ----------------------------------------------------------------------------------------------------- > > Key: ARQ-1820 > URL: https://issues.jboss.org/browse/ARQ-1820 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Miroslav Novak > > There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: > - Start two EAP 6.3.0.ER9 servers > - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) > - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server > - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server > - Kill -9 "first EAP server" > - Producer and consumer failovers to backup > Problem: > When producer and consumer failovers to backup then it fails with: > {code} > 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover > HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) > at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) > at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) > at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > Second EAP server logs: > {code} > 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > {code} > It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that > javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: > {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} > When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 15:12:29 2014 From: issues at jboss.org (Raymond Auge (JIRA)) Date: Thu, 17 Jul 2014 15:12:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1821) equinox container does not install bundles specified in framework properties In-Reply-To: References: Message-ID: Raymond Auge created ARQ-1821: --------------------------------- Summary: equinox container does not install bundles specified in framework properties Key: ARQ-1821 URL: https://issues.jboss.org/browse/ARQ-1821 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: OSGi Containers Environment: arquillian-container-equinox-embedded 2.1.0.CR15 arquillian-junit-container 1.1.2.Final org.eclipse.osgi 3.9.1.v20130814-1242 Reporter: Raymond Auge Assignee: Thomas Diesler Priority: Blocker The container assumes that equinox will start bundles passed in the framework properties as 'osgi.bundles'. However this loading feature is not available in equinox when using the osgi Framework API, but only when using the proprietary EclipseStarter class. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 16:58:29 2014 From: issues at jboss.org (Raymond Auge (JIRA)) Date: Thu, 17 Jul 2014 16:58:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1821) equinox container does not install bundles specified in framework properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986063#comment-12986063 ] Raymond Auge commented on ARQ-1821: ----------------------------------- This may be partially due to the fact that arquillian is using an ancient equinox dependency and so perhaps the integration tests are all good because if this. The pom for arquillian-container-equinox defines a dependency on: {code} org.eclipse.osgi org.eclipse.osgi {code} the newest version of this artifact is 3.7.1, which is ancient in terms of equinox. I recommend changing the dependency to this maven group: {code} org.eclipse.tycho org.eclipse.osgi {code} However, this will cause the issue to come to light and then there might be either a helper code required since this module will not support any auto starting of bundles. Or perhaps a small framework extension bundle can be created which adds the functionality something like felix's framework + main bundles. > equinox container does not install bundles specified in framework properties > ---------------------------------------------------------------------------- > > Key: ARQ-1821 > URL: https://issues.jboss.org/browse/ARQ-1821 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Environment: arquillian-container-equinox-embedded 2.1.0.CR15 > arquillian-junit-container 1.1.2.Final > org.eclipse.osgi 3.9.1.v20130814-1242 > Reporter: Raymond Auge > Assignee: Thomas Diesler > Priority: Blocker > > The container assumes that equinox will start bundles passed in the framework properties as 'osgi.bundles'. > However this loading feature is not available in equinox when using the osgi Framework API, but only when using the proprietary EclipseStarter class. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 17:00:29 2014 From: issues at jboss.org (Raymond Auge (JIRA)) Date: Thu, 17 Jul 2014 17:00:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1821) equinox container does not install bundles specified in framework properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Auge updated ARQ-1821: ------------------------------ Steps to Reproduce: Configure the framework properties with some required bundles passed via {{osgi.bundles}} property. Configure the test container using {{arquillian-container-equinox-embedded}}. *Note* the required bundles are never installed. *Note* must use a recent version of equinox. was: Configure the framework properties with some required bundles passed via {{osgi.bundles}} property. Configure the test container using {{arquillian-container-equinox-embedded}}. Note the required bundles are never installed. > equinox container does not install bundles specified in framework properties > ---------------------------------------------------------------------------- > > Key: ARQ-1821 > URL: https://issues.jboss.org/browse/ARQ-1821 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Environment: arquillian-container-equinox-embedded 2.1.0.CR15 > arquillian-junit-container 1.1.2.Final > org.eclipse.osgi 3.9.1.v20130814-1242 > Reporter: Raymond Auge > Assignee: Thomas Diesler > Priority: Blocker > > The container assumes that equinox will start bundles passed in the framework properties as 'osgi.bundles'. > However this loading feature is not available in equinox when using the osgi Framework API, but only when using the proprietary EclipseStarter class. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 17:04:29 2014 From: issues at jboss.org (Raymond Auge (JIRA)) Date: Thu, 17 Jul 2014 17:04:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1821) equinox container does not install bundles specified in framework properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986063#comment-12986063 ] Raymond Auge edited comment on ARQ-1821 at 7/17/14 5:03 PM: ------------------------------------------------------------ This may be partially due to the fact that arquillian is using an ancient equinox dependency and so perhaps the integration tests are all good because if this. The pom for arquillian-container-equinox defines a dependency on: {code} org.eclipse.osgi org.eclipse.osgi {code} the newest version of this artifact is 3.7.1, which is ancient in terms of equinox. I recommend changing the dependency to this maven group: {code} org.eclipse.tycho org.eclipse.osgi {code} However, this will cause the issue to come to light and then there might need either * helper code to read properties to start the dependent bundles directly * a small framework extension bundle which adds the auto start functionality was (Author: rotty): This may be partially due to the fact that arquillian is using an ancient equinox dependency and so perhaps the integration tests are all good because if this. The pom for arquillian-container-equinox defines a dependency on: {code} org.eclipse.osgi org.eclipse.osgi {code} the newest version of this artifact is 3.7.1, which is ancient in terms of equinox. I recommend changing the dependency to this maven group: {code} org.eclipse.tycho org.eclipse.osgi {code} However, this will cause the issue to come to light and then there might be either a helper code required since this module will not support any auto starting of bundles. Or perhaps a small framework extension bundle can be created which adds the functionality something like felix's framework + main bundles. > equinox container does not install bundles specified in framework properties > ---------------------------------------------------------------------------- > > Key: ARQ-1821 > URL: https://issues.jboss.org/browse/ARQ-1821 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Environment: arquillian-container-equinox-embedded 2.1.0.CR15 > arquillian-junit-container 1.1.2.Final > org.eclipse.osgi 3.9.1.v20130814-1242 > Reporter: Raymond Auge > Assignee: Thomas Diesler > Priority: Blocker > > The container assumes that equinox will start bundles passed in the framework properties as 'osgi.bundles'. > However this loading feature is not available in equinox when using the osgi Framework API, but only when using the proprietary EclipseStarter class. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 05:26:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Fri, 18 Jul 2014 05:26:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1822) Bash script output is not always propagated In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1822: -------------------------------- Summary: Bash script output is not always propagated Key: ARQ-1822 URL: https://issues.jboss.org/browse/ARQ-1822 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Spacelift Affects Versions: spacelift_1.0.0.Alpha2 Reporter: Karel Piwko It looks like Spacelift interaction for processes is not always able to figure out content of the line. Regex should be compiled with http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#DOTALL -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 05:28:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Fri, 18 Jul 2014 05:28:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1822) Bash script output is not always propagated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986187#comment-12986187 ] Karel Piwko commented on ARQ-1822: ---------------------------------- https://github.com/arquillian/arquillian-spacelift/blob/master/spacelift-api/src/main/java/org/arquillian/spacelift/process/ProcessInteractionBuilder.java#L141-L144 > Bash script output is not always propagated > ------------------------------------------- > > Key: ARQ-1822 > URL: https://issues.jboss.org/browse/ARQ-1822 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha2 > Reporter: Karel Piwko > Labels: Starter > > It looks like Spacelift interaction for processes is not always able to figure out content of the line. > Regex should be compiled with http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#DOTALL -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 05:28:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Fri, 18 Jul 2014 05:28:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1822) Bash script output is not always propagated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1822: ----------------------------- Labels: Starter (was: ) > Bash script output is not always propagated > ------------------------------------------- > > Key: ARQ-1822 > URL: https://issues.jboss.org/browse/ARQ-1822 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha2 > Reporter: Karel Piwko > Labels: Starter > > It looks like Spacelift interaction for processes is not always able to figure out content of the line. > Regex should be compiled with http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#DOTALL -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 19 08:54:29 2014 From: issues at jboss.org (Schuller Tom (JIRA)) Date: Sat, 19 Jul 2014 08:54:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1235) "@ArquillianResource URL contexPath" is resolved to "http:/0.0.0.0:8080/deploypath" when using -b 0.0.0.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986463#comment-12986463 ] Schuller Tom commented on ARQ-1235: ----------------------------------- any solution/workaround on this? > "@ArquillianResource URL contexPath" is resolved to "http:/0.0.0.0:8080/deploypath" when using -b 0.0.0.0 > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1235 > URL: https://issues.jboss.org/browse/ARQ-1235 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JBoss AS Containers > Affects Versions: 1.0.3.Final > Environment: Windows 7 and AS7.1.1 with remote-container connector > Reporter: Jos? Freitas > > @ArquillianResource > URL contextPath; > gets resolved to: > http://0.0.0.0:8080/15ff0138-935a-44be-a84f-73263a88df6a/ > and it should return a public adress so it can connect to the server when @Deployment(testable = false) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 06:19:29 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 21 Jul 2014 06:19:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986584#comment-12986584 ] Aslak Knutsen commented on ARQ-1820: ------------------------------------ You're running a in-container test using the AS7-JMX Protocol here? > LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian > ----------------------------------------------------------------------------------------------------- > > Key: ARQ-1820 > URL: https://issues.jboss.org/browse/ARQ-1820 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Miroslav Novak > > There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: > - Start two EAP 6.3.0.ER9 servers > - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) > - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server > - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server > - Kill -9 "first EAP server" > - Producer and consumer failovers to backup > Problem: > When producer and consumer failovers to backup then it fails with: > {code} > 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover > HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) > at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) > at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) > at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > Second EAP server logs: > {code} > 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > {code} > It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that > javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: > {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} > When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 06:29:29 2014 From: issues at jboss.org (Miroslav Novak (JIRA)) Date: Mon, 21 Jul 2014 06:29:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1820) LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986586#comment-12986586 ] Miroslav Novak commented on ARQ-1820: ------------------------------------- No, I'm using "Servlet 3.0" protocol. There is no deployment to EAP 6 server. Server is started manually in the test. arquillian.xml: {code} ${JBOSS_HOME_1} -Xms64m -Xmx788m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_1},port:9091 -Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR} -Djboss.bind.address=${MYTESTIP_1} -Djboss.bind.address.management=${MYTESTIP_1} -Djboss.bind.address.unsecure=${MYTESTIP_1} -Djboss.messaging.group.address=${MCAST_ADDR} -Djboss.default.multicast.address=${MCAST_ADDR} -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=false -Djboss.modules.policy-permissions=true standalone-full-ha.xml 60 ${MYTESTIP_1} admin minono532/20 ${JBOSS_HOME_2} -Xms64m -Xmx788m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_2},port:9191 -Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR} -Djboss.bind.address=${MYTESTIP_2} -Djboss.bind.address.management=${MYTESTIP_2} -Djboss.bind.address.unsecure=${MYTESTIP_2} -Djboss.messaging.group.address=${MCAST_ADDR} -Djboss.default.multicast.address=${MCAST_ADDR} -Djboss.modules.policy-permissions=true -XX:+HeapDumpOnOutOfMemoryError -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8787,server=y,suspend=n standalone-full-ha.xml 60 ${MYTESTIP_2} admin minono532/20 ${JBOSS_HOME_3} -Xms64m -Xmx788m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_3},port:9291 -Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR} -Djboss.bind.address=${MYTESTIP_3} -Djboss.bind.address.management=${MYTESTIP_3} -Djboss.bind.address.unsecure=${MYTESTIP_3} -Djboss.messaging.group.address=${MCAST_ADDR} -Djboss.default.multicast.address=${MCAST_ADDR} -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=false standalone-full-ha.xml 60 ${MYTESTIP_3} admin minono532/20 ${JBOSS_HOME_4} -Xms64m -Xmx788m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -javaagent:${BYTEMAN_JAR}=prop:org.jboss.byteman.verbose=true,address:${MYTESTIP_4},port:9391 -Djboss.modules.system.pkgs=org.jboss.byteman -Xbootclasspath/a:${BYTEMAN_JAR}:${BYTEMAN_SUBMIT_JAR} -Djboss.bind.address=${MYTESTIP_4} -Djboss.bind.address.management=${MYTESTIP_4} -Djboss.bind.address.unsecure=${MYTESTIP_4} -Djboss.messaging.group.address=${MCAST_ADDR} -Djboss.default.multicast.address=${MCAST_ADDR} -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=false standalone-full-ha.xml 60 ${MYTESTIP_4} admin minono532/20 {code} I'll provide a reproducer. > LoginContext cannot load login modules in certain scenarios when EAP server is started by Arquillian > ----------------------------------------------------------------------------------------------------- > > Key: ARQ-1820 > URL: https://issues.jboss.org/browse/ARQ-1820 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Miroslav Novak > > There is problem with classloading when EAP 6.3.0.ER9 server is started by Arquillian. Problem was hit in following test scenario: > - Start two EAP 6.3.0.ER9 servers > - HornetQ is configured in collocated HA topology with shared store (EAP servers contains HornetQ backup for each other - so there are 2 live/backup pairs) > - Start producer which sends messages to "jms/queue/testQueue0" to first EAP server > - Start consumer which receives messages from "jms/queue/testQueue0" to first EAP server > - Kill -9 "first EAP server" > - Producer and consumer failovers to backup > Problem: > When producer and consumer failovers to backup then it fails with: > {code} > 13:58:40,146 Thread-2 (HornetQ-client-global-threads-2060674296) ERROR [org.hornetq.core.client.impl.ClientSessionImpl:1198] HQ214003: Failed to handle failover > HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394) > at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1087) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:1075) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:717) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:587) > at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionException(ClientSessionFactoryImpl.java:441) > at org.hornetq.core.remoting.impl.netty.NettyConnector$Listener$2.run(NettyConnector.java:924) > at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > Second EAP server logs: > {code} > 13:58:40,144 ERROR [org.hornetq.core.server] (Old I/O server worker (parentId: 223510377, [id: 0x0d527f69, /192.168.40.2:5446])) HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null] > at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:146) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:979) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:78) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:636) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:547) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:523) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:564) [hornetq-server-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:72) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:281) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-client-2.3.20.Final-redhat-1.jar:2.3.20.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.process(OioWorker.java:71) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:73) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175) [netty-3.6.9.Final-redhat-1.jar:3.6.9.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > {code} > It failed because it was not authenticated on second EAP server. When debugging the problem I figured that root cause for this failure is that > javax.security.auth.login.LoginContext.invoke(String methodName):746 is using reflection to load class - org.jboss.as.security.RealmDirectLoginModule which was not found in provided classloader: > {code}Class c = Class.forName(moduleStack[i].entry.getLoginModuleName(), true, contextClassLoader);{code} > When I try the same test scenario manually then producer and consumer failovers without problem (=authenticates). Is there a way how EAP 6 classloader can be influenced by Arquillian? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 08:01:37 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 21 Jul 2014 08:01:37 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1823) ChromeBinary is not picked by ChromeDriver In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1823: -------------------------------- Summary: ChromeBinary is not picked by ChromeDriver Key: ARQ-1823 URL: https://issues.jboss.org/browse/ARQ-1823 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: drone_2.0.0.Alpha2 Reporter: Karel Piwko It looks like that capability is not used by upstream implementation. We need to make it a part of ChromeOptions instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 08:35:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 21 Jul 2014 08:35:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1824) Support Google Inc.:Google APIs (x86 System Image):19 format In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1824: -------------------------------- Summary: Support Google Inc.:Google APIs (x86 System Image):19 format Key: ARQ-1824 URL: https://issues.jboss.org/browse/ARQ-1824 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha5 Reporter: Karel Piwko With new version format in Android SDK, we need to alter parsing options to support '()' in target format. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:23:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:23:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: Juraj H?ska created ARQGRA-455: ---------------------------------- Summary: Guarded XHR2 request fails when its onload callback is JQuery proxy Key: ARQGRA-455 URL: https://issues.jboss.org/browse/ARQGRA-455 Project: Arquillian Graphene Issue Type: Bug Security Level: Public (Everyone can see) Components: core Affects Versions: 2.0.3.Final Reporter: Juraj H?ska If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. *XHR2 request*: {code:javascript} function makeXHR2() { var xhr = new XMLHttpRequest(); xhr.open("GET", "sample1.html", true); xhr.responseType = 'text'; xhr.onload = $.proxy(function (e) { switch (e.target.status) { case 200: console.log('HTTP 200'); break; default: console.log('HTTP 500'); } var responseContext = { } }, this); xhr.send(null); } {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:25:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:25:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQGRA-455: ------------------------------- Description: If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. *XHR2 request*: {code:javascript} function makeXHR2() { var xhr = new XMLHttpRequest(); xhr.open("GET", "sample1.html", true); xhr.responseType = 'text'; xhr.onload = $.proxy(function (e) { switch (e.target.status) { case 200: console.log('HTTP 200'); break; default: console.log('HTTP 500'); } var responseContext = { } }, this); xhr.send(null); } {code} In browser console there is an error that states: {code} e.target is undefined {code} was: If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. *XHR2 request*: {code:javascript} function makeXHR2() { var xhr = new XMLHttpRequest(); xhr.open("GET", "sample1.html", true); xhr.responseType = 'text'; xhr.onload = $.proxy(function (e) { switch (e.target.status) { case 200: console.log('HTTP 200'); break; default: console.log('HTTP 500'); } var responseContext = { } }, this); xhr.send(null); } {code} > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:25:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:25:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986681#comment-12986681 ] Juraj H?ska commented on ARQGRA-455: ------------------------------------ Reproducer and test added to this branch: https://github.com/arquillian/arquillian-graphene/tree/ARQGRA-455 > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:27:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:27:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQGRA-455: ------------------------------- Steps to Reproduce: # clone [this|https://github.com/arquillian/arquillian-graphene/tree/ARQGRA-455] branch. # from module _ftest_ run: {{mvn clean verify -Pwebdriver-firefox -Dtest=TestXHR2OnloadAsProxy}} > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:33:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:33:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986689#comment-12986689 ] Juraj H?ska commented on ARQGRA-455: ------------------------------------ When I am comparing the content of the {{e}} argument which is passed to the callback, I get following: * *Without* using of {{guardAjax}} {code} load { target: XMLHttpRequest, lengthComputable: true, loaded: 33893, total: 33893, isTrusted: true, eventPhase: 0, bubbles: false, cancelable: false, defaultPrevented: false, timeStamp: 1405946241825187, originalTarget: XMLHttpRequest } {code} * *With* using of {{guardAjax}} {code} Object { guarded: true, callbackCount: 0, changeState: enhanceXhrObject/xhr.changeState(), tryFinish: enhanceXhrObject/xhr.tryFinish(), proceedWithCallbacks: enhanceXhrObject/xhr.proceedWithCallbacks(), isGuarded: enhanceXhrObject/xhr.isGuarded(), xhr: XMLHttpRequest, readyState: 4, response: "", responseType: "", 10 more? } {code} Which gives me impression that {{e}} is the XHR request itself when using {{guardAjax}}, instead of the right version, where {{e.target}} is the XHR request. > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:35:40 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:35:40 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986692#comment-12986692 ] Juraj H?ska commented on ARQGRA-455: ------------------------------------ Hey [~okiss] , you are JS ninja, any insight or hint please ? > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:35:40 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:35:40 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986692#comment-12986692 ] Juraj H?ska edited comment on ARQGRA-455 at 7/21/14 10:34 AM: -------------------------------------------------------------- Hey [~okiss] , you are JS ninja recently adding the XHR2 support. Any insight or hint please ? was (Author: jhuska): Hey [~okiss] , you are JS ninja, any insight or hint please ? > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:35:42 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:35:42 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQGRA-455: ------------------------------- Description: If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. *XHR2 request*: {code:javascript} function makeXHR2() { var xhr = new XMLHttpRequest(); xhr.open("GET", "sample1.html", true); xhr.responseType = 'text'; xhr.onload = $.proxy(function (e) { switch (e.target.status) { case 200: console.log('HTTP 200'); break; default: console.log('HTTP 500'); } var responseContext = { } }, this); xhr.send(null); } {code} In browser console there is an error that states: {code} e.target is undefined {code} was: If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. *XHR2 request*: {code:javascript} function makeXHR2() { var xhr = new XMLHttpRequest(); xhr.open("GET", "sample1.html", true); xhr.responseType = 'text'; xhr.onload = $.proxy(function (e) { switch (e.target.status) { case 200: console.log('HTTP 200'); break; default: console.log('HTTP 500'); } var responseContext = { } }, this); xhr.send(null); } {code} In browser console there is an error that states: {code} e.target is undefined {code} > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:37:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 10:37:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQGRA-455: ------------------------------- Description: If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. *XHR2 request*: {code:javascript} function makeXHR2() { var xhr = new XMLHttpRequest(); xhr.open("GET", "sample1.html", true); xhr.responseType = 'text'; xhr.onload = $.proxy(function (e) { switch (e.target.status) { case 200: console.log('HTTP 200'); break; default: console.log('HTTP 500'); } var responseContext = { } }, this); xhr.send(null); } {code} In browser console there is an error that states: {code} e.target is undefined {code} was: If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. *XHR2 request*: {code:javascript} function makeXHR2() { var xhr = new XMLHttpRequest(); xhr.open("GET", "sample1.html", true); xhr.responseType = 'text'; xhr.onload = $.proxy(function (e) { switch (e.target.status) { case 200: console.log('HTTP 200'); break; default: console.log('HTTP 500'); } var responseContext = { } }, this); xhr.send(null); } {code} In browser console there is an error that states: {code} e.target is undefined {code} > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 05:27:29 2014 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Tue, 22 Jul 2014 05:27:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1825) ManagementClient push auth callback even without data In-Reply-To: References: Message-ID: Bartosz Baranowski created ARQ-1825: --------------------------------------- Summary: ManagementClient push auth callback even without data Key: ARQ-1825 URL: https://issues.jboss.org/browse/ARQ-1825 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Bartosz Baranowski Fix For: 1.0.0.Alpha2 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 15:15:34 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 22 Jul 2014 15:15:34 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1825) ManagementClient push auth callback even without data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987216#comment-12987216 ] Aslak Knutsen commented on ARQ-1825: ------------------------------------ Got some more info here? > ManagementClient push auth callback even without data > ----------------------------------------------------- > > Key: ARQ-1825 > URL: https://issues.jboss.org/browse/ARQ-1825 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Fix For: 1.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 04:39:30 2014 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Wed, 23 Jul 2014 04:39:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1825) ManagementClient push auth callback even without data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987329#comment-12987329 ] Bartosz Baranowski commented on ARQ-1825: ----------------------------------------- Also: https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main/java/org/jboss/as/arquillian/container/ManagementClient.java#L343 vs https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main/java/org/jboss/as/arquillian/container/ManagementClient.java#L685 > ManagementClient push auth callback even without data > ----------------------------------------------------- > > Key: ARQ-1825 > URL: https://issues.jboss.org/browse/ARQ-1825 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Fix For: 1.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 11:21:31 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Wed, 23 Jul 2014 11:21:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1536) Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1536: ----------------------------------- Fix Version/s: droidium_1.0.0.Beta1 > Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1536 > URL: https://issues.jboss.org/browse/ARQ-1536 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Fix For: droidium_1.0.0.Beta1 > > > Instead of starting activity every time in test method manually, it would be nice to have this possibility: > {code} > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > public void loginUserInMobile(@ArquillianResource AndroidDevice device) { > device.getActivityManagerProvider() > .getActivityManager() > .startActivity("org.jboss.aerogear.todo.activities.LoginActivity"); > loginMobileFragment.login("john", "123"); > } > ========================= > @Test > @InSequence(4) > @OperateOnDeployment("todo-mobile-app") > @StartActivity("org.jboss.aerogear.todo.activities.LoginActivity") > public void loginUserInMobile() { > loginMobileFragment.login("john", "123"); > } > {code} > However, with the possibility to have Graphene page fragments, it would be teoretically possible to have propper page objects as well which mean that we could abstract activity into @Page and specify its @Location("activityName") > The problem is, how this translates to Graphene since Droidium starts activities in this manner: > driver.get("and-activity://" + activityName); > There is the need to take that "and-activity" string into consideration with @Location annotation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 03:29:30 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 24 Jul 2014 03:29:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987565#comment-12987565 ] Luk?? Fry? commented on ARQGRA-455: ----------------------------------- I wounder whether it is caused by {{XHRInterception.js}} copying just some of the XHR attributes: https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/javascript/Graphene.xhrInterception.js#L130 If that is the issue, we should "copy" all the attributes that are exposed at the time of the request. This would be future proof solution. > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 07:39:29 2014 From: issues at jboss.org (=?UTF-8?Q?Oliver_Ki=C5=A1=C5=A1_=28JIRA=29?=) Date: Thu, 24 Jul 2014 07:39:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987647#comment-12987647 ] Oliver Ki?? commented on ARQGRA-455: ------------------------------------ [~lfryc] I think the problem is that the wrapper we pass to {{onload/onreadystatechange}} copies {{XMLHttpRequest}} attributes, but If Graphene is not used the object passed to the onload handler is an instance of {{XMLHttpRequestProgressEvent}}, not {{XMLHttpRequest}}. > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 09:45:29 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 24 Jul 2014 09:45:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987712#comment-12987712 ] Luk?? Fry? commented on ARQGRA-455: ----------------------------------- Makes sense. > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:07:29 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Thu, 24 Jul 2014 10:07:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1826) Download Explorer binary for Drone In-Reply-To: References: Message-ID: Stefan Miklosovic created ARQ-1826: -------------------------------------- Summary: Download Explorer binary for Drone Key: ARQ-1826 URL: https://issues.jboss.org/browse/ARQ-1826 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: drone_2.0.0.Alpha2 Reporter: Stefan Miklosovic -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:13:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 24 Jul 2014 10:13:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987729#comment-12987729 ] Juraj H?ska commented on ARQGRA-455: ------------------------------------ [~lfryc] do you have please any suggestion how to resolve this ? This issue is pretty much blocking the testing of RichFaces FileUpload component, as it uses XHR2 requests now. > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:21:31 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 24 Jul 2014 10:21:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987737#comment-12987737 ] Luk?? Fry? commented on ARQGRA-455: ----------------------------------- [~okiss] would you like to give a fix try? > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:39:32 2014 From: issues at jboss.org (=?UTF-8?Q?Oliver_Ki=C5=A1=C5=A1_=28JIRA=29?=) Date: Thu, 24 Jul 2014 10:39:32 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987754#comment-12987754 ] Oliver Ki?? commented on ARQGRA-455: ------------------------------------ [~lfryc] sure > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:49:29 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 24 Jul 2014 10:49:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-455) Guarded XHR2 request fails when its onload callback is JQuery proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987764#comment-12987764 ] Luk?? Fry? commented on ARQGRA-455: ----------------------------------- [~jhuska] I don't think there is any workaround, you can avoud using guards for this tests for now. The resolution means we stick with the specification / implementations out there. By debugging you can reveal from where the {{e}} (event) parameter comes and how it is treated. > Guarded XHR2 request fails when its onload callback is JQuery proxy > ------------------------------------------------------------------- > > Key: ARQGRA-455 > URL: https://issues.jboss.org/browse/ARQGRA-455 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.3.Final > Reporter: Juraj H?ska > > If Graphene is guarding an AJAX request, which {{onload}} callback is JQUery proxy, then it fails. There is a problem with arguments passing. > *XHR2 request*: > {code:javascript} > function makeXHR2() { > var xhr = new XMLHttpRequest(); > xhr.open("GET", "sample1.html", true); > xhr.responseType = 'text'; > > xhr.onload = $.proxy(function (e) { > switch (e.target.status) { > case 200: > console.log('HTTP 200'); > break; > default: > console.log('HTTP 500'); > } > > var responseContext = { > } > }, this); > > xhr.send(null); > } > {code} > In browser console there is an error that states: > {code} > e.target is undefined > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 05:43:33 2014 From: issues at jboss.org (Xavier Lannoye (JIRA)) Date: Fri, 25 Jul 2014 05:43:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1782) @UsingDataSet/@ShouldMatchDataSet always makes test succeed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987956#comment-12987956 ] Xavier Lannoye commented on ARQ-1782: ------------------------------------- Same issue for me, same solution too (downgrading arq to 1.1.3-FINAL) > @UsingDataSet/@ShouldMatchDataSet always makes test succeed > ----------------------------------------------------------- > > Key: ARQ-1782 > URL: https://issues.jboss.org/browse/ARQ-1782 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha7 > Environment: WildFly 8 CR 2 > Reporter: Nicklas Karlsson > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > {code:xml} > > xsi:schemaLocation=" > http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > fi.affecto.marela > arq-concept > 1.0.0-SNAPSHOT > jar > > UTF-8 > chrome > > > > > org.jboss.arquillian > arquillian-bom > 1.1.4.Final > import > pom > > > org.jboss.arquillian.extension > arquillian-drone-bom > 1.3.0.Final > pom > import > > > org.jboss.arquillian.selenium > selenium-bom > 2.41.0 > pom > import > > > > > > junit > junit > 4.11 > test > > > org.jboss.arquillian.junit > arquillian-junit-container > test > > > org.hibernate > hibernate-jpamodelgen > 4.3.5.Final > provided > > > org.jboss.arquillian.graphene > graphene-webdriver > 2.0.2.Final > pom > test > > > org.jboss.arquillian.extension > arquillian-persistence-core > 1.0.0.Alpha7 > > > org.jboss.arquillian.extension > arquillian-persistence-dbunit > 1.0.0.Alpha7 > > > > > arq-wildfly > > > org.jboss.spec > jboss-javaee-7.0 > 1.0.0.Final > pom > provided > > > org.wildfly > wildfly-arquillian-container-remote > 8.1.0.CR2 > test > > > org.jboss.arquillian.protocol > arquillian-protocol-servlet > test > > > > > > > > maven-compiler-plugin > 2.3.2 > > 1.7 > 1.7 > > > > > > src/test/resources > true > > > > > {code} > {code:java} > package fi.affecto.marela.test; > import javax.inject.Inject; > import javax.persistence.EntityManager; > import javax.persistence.PersistenceContext; > import javax.transaction.UserTransaction; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.arquillian.persistence.ShouldMatchDataSet; > import org.jboss.arquillian.persistence.UsingDataSet; > import org.jboss.arquillian.transaction.api.annotation.Transactional; > import org.jboss.shrinkwrap.api.Archive; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.asset.EmptyAsset; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.junit.Assert; > import org.junit.Test; > import org.junit.runner.RunWith; > import fi.affecto.marela.jpa.Game; > @RunWith(Arquillian.class) > public class PersistenceExtensionTest > { > @Deployment > public static Archive createDeployment() > { > return ShrinkWrap.create(WebArchive.class, "test.war").addPackage(Game.class.getPackage()) > .addAsResource("persistence.xml", "META-INF/persistence.xml") > .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml"); > } > @PersistenceContext > EntityManager em; > @Inject > UserTransaction utx; > @Test > public void testA() throws Exception > { > Assert.assertNotNull(em); > utx.begin(); > // em.joinTransaction(); > Game g = new Game(); > g.setId(666L); > g.setTitle("x"); > Assert.assertFalse(em.contains(g)); > g = em.merge(g); > Assert.assertTrue(em.contains(g)); > utx.rollback(); > } > > @Test > @Transactional > public void testB() throws Exception > { > Assert.assertNotNull(em); > Game g = new Game(); > g.setId(666L); > g.setTitle("x"); > Assert.assertFalse(em.contains(g)); > g = em.merge(g); > Assert.assertTrue(em.contains(g)); > } > @Test > // @UsingDataSet("games.yml") > // @ShouldMatchDataSet("games-check.yml") > @Transactional > public void testC() throws Exception > { > Assert.assertTrue(false); > } > } > {code} > testC succeeds if the annotations are uncommented. > Furthermore, there is something strange with the em/transactions, the persistence works even if the em doesn't join the transaction and the em complains of a detached instance if merge() is switched for persist() -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 04:37:30 2014 From: issues at jboss.org (Martin Swiech (JIRA)) Date: Mon, 28 Jul 2014 04:37:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1827) The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests In-Reply-To: References: Message-ID: Martin Swiech created ARQ-1827: ---------------------------------- Summary: The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests Key: ARQ-1827 URL: https://issues.jboss.org/browse/ARQ-1827 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: OSGi Containers Affects Versions: 1.1.0.Final Reporter: Martin Swiech Assignee: Thomas Diesler Priority: Minor The annotation @StartLevelAware(autostart = true) doesn't have effect to start test bundle under Karaf environment in case of @RunAsClient tests. I must use property true in arquillian configuration.xml to start test bundle. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 04:39:30 2014 From: issues at jboss.org (Martin Swiech (JIRA)) Date: Mon, 28 Jul 2014 04:39:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1827) The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Swiech updated ARQ-1827: ------------------------------- Labels: client deployer osgi test (was: ) Workaround Description: Use true in arquillian.xml Workaround: Workaround Exists > The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests > ------------------------------------------------------------------------------------------------------ > > Key: ARQ-1827 > URL: https://issues.jboss.org/browse/ARQ-1827 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Affects Versions: 1.1.0.Final > Reporter: Martin Swiech > Assignee: Thomas Diesler > Priority: Minor > Labels: client, deployer, osgi, test > > The annotation @StartLevelAware(autostart = true) doesn't have effect to start test bundle under Karaf environment in case of @RunAsClient tests. > I must use property > true > in arquillian configuration.xml to start test bundle. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 04:43:29 2014 From: issues at jboss.org (Martin Swiech (JIRA)) Date: Mon, 28 Jul 2014 04:43:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1827) The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Swiech updated ARQ-1827: ------------------------------- Steps to Reproduce: 1. Create some test bundle to run on Karaf environment. 2. Create @RunAsClient test in this bundle with deployment annotation @StartLevelAware(autostart = true). 3. There could not be property "autostartBundle" in arquillian.xml . 4. Run test using maven R: Test bundle under karaf is installed, but no activated. E: Test bundle under karaf is installed and active. was: 1. Create some test bundle to run on Karaf environment. 2. Create @RunAsClient test in this bundle with deployment annotation @StartLevelAware(autostart = true). 3. arquillian.xml must not has property "autostartBundle" 4. Run test using maven R: Test bundle under karaf is installed, but no activated. E: Test bundle under karaf is installed and active. > The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests > ------------------------------------------------------------------------------------------------------ > > Key: ARQ-1827 > URL: https://issues.jboss.org/browse/ARQ-1827 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Affects Versions: 1.1.0.Final > Reporter: Martin Swiech > Assignee: Thomas Diesler > Priority: Minor > Labels: client, deployer, osgi, test > > The annotation @StartLevelAware(autostart = true) doesn't have effect to start test bundle under Karaf environment in case of @RunAsClient tests. > I must use property > true > in arquillian configuration.xml to start test bundle. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 09:51:30 2014 From: issues at jboss.org (Martin Basovnik (JIRA)) Date: Mon, 28 Jul 2014 09:51:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1827) The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988305#comment-12988305 ] Martin Basovnik commented on ARQ-1827: -------------------------------------- Method [{{getBundle()}}|https://github.com/arquillian/arquillian-container-osgi/blob/master/testenricher/src/main/java/org/jboss/arquillian/testenricher/osgi/OSGiTestEnricher.java#L64] returns {{null}} when we use annotation {{@RunAsClient}}. > The @StartLevelAware(autostart = true) does not work with karaf deployer in case of @RunAsClient tests > ------------------------------------------------------------------------------------------------------ > > Key: ARQ-1827 > URL: https://issues.jboss.org/browse/ARQ-1827 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Affects Versions: 1.1.0.Final > Reporter: Martin Swiech > Assignee: Thomas Diesler > Priority: Minor > Labels: client, deployer, osgi, test > > The annotation @StartLevelAware(autostart = true) doesn't have effect to start test bundle under Karaf environment in case of @RunAsClient tests. > I must use property > true > in arquillian configuration.xml to start test bundle. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 04:46:31 2014 From: issues at jboss.org (Niels Niels (JIRA)) Date: Tue, 29 Jul 2014 04:46:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1828) Replace Testrunner with a JUnit-Rule In-Reply-To: References: Message-ID: Niels Niels created ARQ-1828: -------------------------------- Summary: Replace Testrunner with a JUnit-Rule Key: ARQ-1828 URL: https://issues.jboss.org/browse/ARQ-1828 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Niels Niels At the moment all tests must run with @RunWith(Arquillian.class) This makes trouble if you need a runner with add or remove tests like Parameterized. I can't see what Arquillian.class do which can not be done with a JUnit-Rule. JUnit-Rules can be easily combined. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 10:32:31 2014 From: issues at jboss.org (Rafael Pestano (JIRA)) Date: Tue, 29 Jul 2014 10:32:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1444) Oracle does not support query delimiter inside statements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988691#comment-12988691 ] Rafael Pestano commented on ARQ-1444: ------------------------------------- Hi guys, sorry for bothering you, oracle really solves the issue with the delimite. The clue here is to use TestExecutionPhase.AFTER to see the real error cause after solving the delimiter problem i was receiving a constaint exception and the error was hidden in BEFORE phase. thanks > Oracle does not support query delimiter inside statements > --------------------------------------------------------- > > Key: ARQ-1444 > URL: https://issues.jboss.org/browse/ARQ-1444 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Environment: Oracle Database. > Reporter: Michel Graciano > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.Alpha7 > > > When we try to use @ApplyScriptBefore and the script file has more than one statement, we use ; as delimiter. The problem is that the delimiter is not removed from the statement before run it, so Oracle database return the following exception: > Caused by: java.sql.SQLSyntaxErrorException: ORA-00911: invalid character -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 03:58:29 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 03:58:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-450) takeBeforeTest does not work when loading of the page is in JUnit @Before method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-450: ------------------------------ Fix Version/s: 2.1.0.Alpha1 > takeBeforeTest does not work when loading of the page is in JUnit @Before method > -------------------------------------------------------------------------------- > > Key: ARQGRA-450 > URL: https://issues.jboss.org/browse/ARQGRA-450 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: 2.1.0.Alpha1 > > > {{takeBeforeTest}} option is broken, because when there are multiple tests, and the loading of the page is done on {{@Before}} method, then the first test is omitted. > It is because JUnit @Before observer is called before the Graphene Screenshooter one, thus the registration of interceptor which takes screenshots is done quite late. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:02:29 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 04:02:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-408) Provide SPI for custom @Location resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-408: ------------------------------ Fix Version/s: 2.1.0.Alpha1 (was: 2.1-Tracking) > Provide SPI for custom @Location resolution > ------------------------------------------- > > Key: ARQGRA-408 > URL: https://issues.jboss.org/browse/ARQGRA-408 > Project: Arquillian Graphene > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > Priority: Minor > Fix For: 2.1.0.Alpha1 > > > While working with page fragments in Arquillian Droidium for ftesting on Android, I am quite close to be able to use proper page objects with @Location annotations on activities and that in turn means that I could use @InitialPage for native Android activities as well. > Right now, I am starting Android activities like this (1) however I would like to encapsulate activity as the abstraction of a web page like this (2) into @Page and use @Location of it so that activity will be automatically open for me when I do @InitialPage so I get rid of that manual starting of the activity as seen in (1) and I just more stick to Graphene way of doing things. > The problem is that an activity is started differently, to be concrete, I need to call something like > {code} > browser.get("and-activity://activityName"); > {code} > and I need to do some internal matching of activities to WebDrivers. > To be concrete, follow the link (3). > From what I understood, that whole @Location logic is implemented in LocationEnricher the resolution of that url is in getURLFromLocation method. Since it would be theoretically possible to use @Location("and-activity://someActivity"), I would like to see SPI for doing of these things out of Graphene where I could add custom schemes to already existing ones or I could supress the standard behaviour so I can resolve and open locations according to my needs. > (1) > https://github.com/kpiwko/arquillian-safari/blob/master/arquillian-droidium-scenario/src/test/java/org/arquillian/droidium/openblend/AeroGearTestCase.java#L140 > (2) https://github.com/kpiwko/arquillian-safari/blob/master/arquillian-droidium-scenario/src/test/java/org/arquillian/droidium/openblend/fragment/mobile/LoginMobileFragment.java > (3) https://github.com/arquillian/arquillian-droidium/blob/master/droidium-native/arquillian-droidium-native-impl/src/main/java/org/arquillian/droidium/native_/activity/NativeActivityManager.java#L46 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:02:30 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 04:02:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-423) Provide a way to intercept in some order In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-423: ------------------------------ Fix Version/s: 2.1.0.Alpha1 (was: 2.1-Tracking) > Provide a way to intercept in some order > ---------------------------------------- > > Key: ARQGRA-423 > URL: https://issues.jboss.org/browse/ARQGRA-423 > Project: Arquillian Graphene > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Fix For: 2.1.0.Alpha1 > > > Currently all registered interceptors are invoked in non defined order. > It would be handy to provide a way how to define such order. > It is mainly because on of the Graphene interceptors: {{SearchContextInterceptor}} blocks intercepting of {{findBy}} method. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:02:30 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 04:02:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-420) Port unified screenshooter implementation for Graphene into Graphene project itself In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-420: ------------------------------ Fix Version/s: 2.1.0.Alpha1 (was: 2.1-Tracking) > Port unified screenshooter implementation for Graphene into Graphene project itself > ----------------------------------------------------------------------------------- > > Key: ARQGRA-420 > URL: https://issues.jboss.org/browse/ARQGRA-420 > Project: Arquillian Graphene > Issue Type: Task > Security Level: Public(Everyone can see) > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: 2.1.0.Alpha1 > > > Port screenshooter implementation from unified screenshooter repository, [here|https://github.com/smiklosovic/arquillian-unified-recorder/tree/master/implementations/arquillian-browser-screenshooter], > into Graphene project repository. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:30:29 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 04:30:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-446) Add support for Groovy page objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988859#comment-12988859 ] Luk?? Fry? commented on ARQGRA-446: ----------------------------------- Merged, to be released as part of {{2.1.0.Alpha1}} and back-ported to {{2.0.x}} if necessary. > Add support for Groovy page objects > ----------------------------------- > > Key: ARQGRA-446 > URL: https://issues.jboss.org/browse/ARQGRA-446 > Project: Arquillian Graphene > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: configuration, core > Affects Versions: 2.0.2.Final > Reporter: Chris Jones > Fix For: 2.1.0.Alpha1 > > Attachments: graphene-groovy-test.zip, groovy-page-support (fixed paths).patch, groovy-page-support.patch > > > Page objects written in groovy throw a StackOverflowError. There seems to be a recursive issue when proxying groovy's metaclass property. > {code:title=GoogleGroovy.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.graphene.page.Location > import org.openqa.selenium.WebElement > import org.openqa.selenium.support.FindBy > @Location("https://www.google.com/") > public class GoogleGroovy { > @FindBy > WebElement q > def search(String query){ > q.sendKeys(query) > sleep(5000) > } > } > {code} > {code:title=GoogleJava.java|borderStyle=solid} > package test; > import org.jboss.arquillian.graphene.page.Location; > import org.openqa.selenium.WebElement; > import org.openqa.selenium.support.FindBy; > @Location("https://www.google.com/") > public class GoogleJava { > @FindBy > WebElement q; > public void search(String query) throws Exception { > q.sendKeys(query); > Thread.sleep(5000); > } > } > {code} > {code:title=GoogleTestCase.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.drone.api.annotation.Drone > import org.jboss.arquillian.graphene.Graphene > import org.jboss.arquillian.junit.Arquillian > import org.junit.Test > import org.junit.runner.RunWith > import org.openqa.selenium.firefox.FirefoxDriver > @RunWith(Arquillian.class) > class GoogleTestCase { > @Drone > FirefoxDriver driver > @Test > def void testUsingJava(){ > def googleJava = Graphene.goTo(GoogleJava) > googleJava.search("hello world") > } > @Test > def void testUsingGroovy(){ > def googleGroovy = Graphene.goTo(GoogleGroovy) > googleGroovy.search("jello world") > } > } > {code} > {code:title=Stacktrace|borderStyle=solid} > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597979243' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > java.lang.StackOverflowError > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:205) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:229) > at test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8.getMetaClass() > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.checkCall(PogoMetaClassSite.java:59) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:36) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > ..... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 04:42:30 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 04:42:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-446) Add support for Groovy page objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-446: ------------------------------ Assignee: Chris Jones > Add support for Groovy page objects > ----------------------------------- > > Key: ARQGRA-446 > URL: https://issues.jboss.org/browse/ARQGRA-446 > Project: Arquillian Graphene > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: configuration, core > Affects Versions: 2.0.2.Final > Reporter: Chris Jones > Assignee: Chris Jones > Fix For: 2.1.0.Alpha1 > > Attachments: graphene-groovy-test.zip, groovy-page-support (fixed paths).patch, groovy-page-support.patch > > > Page objects written in groovy throw a StackOverflowError. There seems to be a recursive issue when proxying groovy's metaclass property. > {code:title=GoogleGroovy.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.graphene.page.Location > import org.openqa.selenium.WebElement > import org.openqa.selenium.support.FindBy > @Location("https://www.google.com/") > public class GoogleGroovy { > @FindBy > WebElement q > def search(String query){ > q.sendKeys(query) > sleep(5000) > } > } > {code} > {code:title=GoogleJava.java|borderStyle=solid} > package test; > import org.jboss.arquillian.graphene.page.Location; > import org.openqa.selenium.WebElement; > import org.openqa.selenium.support.FindBy; > @Location("https://www.google.com/") > public class GoogleJava { > @FindBy > WebElement q; > public void search(String query) throws Exception { > q.sendKeys(query); > Thread.sleep(5000); > } > } > {code} > {code:title=GoogleTestCase.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.drone.api.annotation.Drone > import org.jboss.arquillian.graphene.Graphene > import org.jboss.arquillian.junit.Arquillian > import org.junit.Test > import org.junit.runner.RunWith > import org.openqa.selenium.firefox.FirefoxDriver > @RunWith(Arquillian.class) > class GoogleTestCase { > @Drone > FirefoxDriver driver > @Test > def void testUsingJava(){ > def googleJava = Graphene.goTo(GoogleJava) > googleJava.search("hello world") > } > @Test > def void testUsingGroovy(){ > def googleGroovy = Graphene.goTo(GoogleGroovy) > googleGroovy.search("jello world") > } > } > {code} > {code:title=Stacktrace|borderStyle=solid} > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597979243' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > java.lang.StackOverflowError > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:205) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:229) > at test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8.getMetaClass() > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.checkCall(PogoMetaClassSite.java:59) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:36) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > ..... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:02:29 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 05:02:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-446) Add support for Groovy page objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-446: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Add support for Groovy page objects > ----------------------------------- > > Key: ARQGRA-446 > URL: https://issues.jboss.org/browse/ARQGRA-446 > Project: Arquillian Graphene > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: configuration, core > Affects Versions: 2.0.2.Final > Reporter: Chris Jones > Assignee: Chris Jones > Fix For: 2.1.0.Alpha1 > > Attachments: graphene-groovy-test.zip, groovy-page-support (fixed paths).patch, groovy-page-support.patch > > > Page objects written in groovy throw a StackOverflowError. There seems to be a recursive issue when proxying groovy's metaclass property. > {code:title=GoogleGroovy.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.graphene.page.Location > import org.openqa.selenium.WebElement > import org.openqa.selenium.support.FindBy > @Location("https://www.google.com/") > public class GoogleGroovy { > @FindBy > WebElement q > def search(String query){ > q.sendKeys(query) > sleep(5000) > } > } > {code} > {code:title=GoogleJava.java|borderStyle=solid} > package test; > import org.jboss.arquillian.graphene.page.Location; > import org.openqa.selenium.WebElement; > import org.openqa.selenium.support.FindBy; > @Location("https://www.google.com/") > public class GoogleJava { > @FindBy > WebElement q; > public void search(String query) throws Exception { > q.sendKeys(query); > Thread.sleep(5000); > } > } > {code} > {code:title=GoogleTestCase.groovy|borderStyle=solid} > package test > import org.jboss.arquillian.drone.api.annotation.Drone > import org.jboss.arquillian.graphene.Graphene > import org.jboss.arquillian.junit.Arquillian > import org.junit.Test > import org.junit.runner.RunWith > import org.openqa.selenium.firefox.FirefoxDriver > @RunWith(Arquillian.class) > class GoogleTestCase { > @Drone > FirefoxDriver driver > @Test > def void testUsingJava(){ > def googleJava = Graphene.goTo(GoogleJava) > googleJava.search("hello world") > } > @Test > def void testUsingGroovy(){ > def googleGroovy = Graphene.goTo(GoogleGroovy) > googleGroovy.search("jello world") > } > } > {code} > {code:title=Stacktrace|borderStyle=solid} > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:08 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597979243' found in test.GoogleTestCase. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__$stMC' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Public field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > Jun 01, 2014 12:47:12 AM org.jboss.arquillian.graphene.enricher.FieldAccessValidatorEnricher checkFieldValidity > WARNING: Package-friendly field '__timeStamp__239_neverHappen1401597978002' found in test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8. Direct access to fields outside of the declaring class is not allowed. > java.lang.StackOverflowError > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:205) > at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.intercept(GrapheneContextualHandler.java:229) > at test.GoogleGroovy$$EnhancerByGraphene$$2eb2d5f8.getMetaClass() > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.checkCall(PogoMetaClassSite.java:59) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:36) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54) > at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) > ..... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:30:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 05:30:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1829) Reporting ScreenshotEntry with phase == onEveryAction is not possible In-Reply-To: References: Message-ID: Juraj H?ska created ARQ-1829: -------------------------------- Summary: Reporting ScreenshotEntry with phase == onEveryAction is not possible Key: ARQ-1829 URL: https://issues.jboss.org/browse/ARQ-1829 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Recorder Affects Versions: 1.0.0.Alpha4 Reporter: Juraj H?ska When I have: {code} ScreenshotEntry propertyEntry = new ScreenshotEntry(); propertyEntry.setPhase(When.ON_EVERY_ACTION); ... propertyReportEvent.fire(new PropertyReportEvent(propertyEntry)); {code} then such a screenshot is not part of the generated report. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:38:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 05:38:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-456) Screenshots made onEveryAction are reported as screenshots made onBefore In-Reply-To: References: Message-ID: Juraj H?ska created ARQGRA-456: ---------------------------------- Summary: Screenshots made onEveryAction are reported as screenshots made onBefore Key: ARQGRA-456 URL: https://issues.jboss.org/browse/ARQGRA-456 Project: Arquillian Graphene Issue Type: Bug Security Level: Public (Everyone can see) Components: screenshooter Affects Versions: 2.1.0.Alpha1 Reporter: Juraj H?ska The problem is that {{TakeScreenshotEvent}} is always fired only with {{onBefore}}. I need to change this phase when appropriate for {{onEveryAction}}. Possible candidates: * before injecting into interceptors, [here|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/ScreenshotTaker.java#L67] * in the interceptor itself, somewhere inside this [block|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/TakeScreenshotOnEveryActionInterceptor.java#L60]. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:46:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 05:46:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-456) Screenshots made onEveryAction are reported as screenshots made onBefore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQGRA-456: ------------------------------- Attachment: wrongOnEveryAction.png > Screenshots made onEveryAction are reported as screenshots made onBefore > ------------------------------------------------------------------------ > > Key: ARQGRA-456 > URL: https://issues.jboss.org/browse/ARQGRA-456 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Attachments: wrongOnEveryAction.png > > > The problem is that {{TakeScreenshotEvent}} is always fired only with {{onBefore}}. > I need to change this phase when appropriate for {{onEveryAction}}. > Possible candidates: > * before injecting into interceptors, [here|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/ScreenshotTaker.java#L67] > * in the interceptor itself, somewhere inside this [block|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/TakeScreenshotOnEveryActionInterceptor.java#L60]. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:48:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 05:48:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-456) Screenshots made onEveryAction are reported as screenshots made onBefore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988881#comment-12988881 ] Juraj H?ska commented on ARQGRA-456: ------------------------------------ See the attachment with screenshot of report. You can see the problem there, exhibited as all screenshots with *Before* phase instead of *On Every Action*. > Screenshots made onEveryAction are reported as screenshots made onBefore > ------------------------------------------------------------------------ > > Key: ARQGRA-456 > URL: https://issues.jboss.org/browse/ARQGRA-456 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Attachments: wrongOnEveryAction.png > > > The problem is that {{TakeScreenshotEvent}} is always fired only with {{onBefore}}. > I need to change this phase when appropriate for {{onEveryAction}}. > Possible candidates: > * before injecting into interceptors, [here|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/ScreenshotTaker.java#L67] > * in the interceptor itself, somewhere inside this [block|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/TakeScreenshotOnEveryActionInterceptor.java#L60]. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 05:48:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 05:48:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-456) Screenshots made onEveryAction are reported as screenshots made onBefore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988882#comment-12988882 ] Juraj H?ska commented on ARQGRA-456: ------------------------------------ Note that when I tried to fix this in Graphene side I encounter a problem on recorder side. Reported as ARQ-1829. > Screenshots made onEveryAction are reported as screenshots made onBefore > ------------------------------------------------------------------------ > > Key: ARQGRA-456 > URL: https://issues.jboss.org/browse/ARQGRA-456 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Attachments: wrongOnEveryAction.png > > > The problem is that {{TakeScreenshotEvent}} is always fired only with {{onBefore}}. > I need to change this phase when appropriate for {{onEveryAction}}. > Possible candidates: > * before injecting into interceptors, [here|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/ScreenshotTaker.java#L67] > * in the interceptor itself, somewhere inside this [block|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/TakeScreenshotOnEveryActionInterceptor.java#L60]. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 06:08:32 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 06:08:32 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-456) Screenshots made onEveryAction are reported as screenshots made onBefore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-456: ------------------------------ Fix Version/s: 2.1.0.Alpha2 > Screenshots made onEveryAction are reported as screenshots made onBefore > ------------------------------------------------------------------------ > > Key: ARQGRA-456 > URL: https://issues.jboss.org/browse/ARQGRA-456 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Fix For: 2.1.0.Alpha2 > > Attachments: wrongOnEveryAction.png > > > The problem is that {{TakeScreenshotEvent}} is always fired only with {{onBefore}}. > I need to change this phase when appropriate for {{onEveryAction}}. > Possible candidates: > * before injecting into interceptors, [here|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/ScreenshotTaker.java#L67] > * in the interceptor itself, somewhere inside this [block|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/TakeScreenshotOnEveryActionInterceptor.java#L60]. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 06:08:33 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 06:08:33 -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? updated ARQGRA-86: ----------------------------- Fix Version/s: 2.1.0.Alpha2 (was: 2.1-Tracking) > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Security Level: Public(Everyone can see) > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 2.1.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 06:48:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 06:48:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1829) Reporting ScreenshotEntry with phase == onEveryAction is not possible In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988906#comment-12988906 ] Juraj H?ska commented on ARQ-1829: ---------------------------------- [~smikloso] pointed out that the problem is [here|https://github.com/arquillian/arquillian-recorder/blob/master/arquillian-recorder-reporter/arquillian-recorder-reporter-api/src/main/resources/arquillian_reporter_templates/en/arquillian_reporter_template.xsl#L271-L301]. > Reporting ScreenshotEntry with phase == onEveryAction is not possible > --------------------------------------------------------------------- > > Key: ARQ-1829 > URL: https://issues.jboss.org/browse/ARQ-1829 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Recorder > Affects Versions: 1.0.0.Alpha4 > Reporter: Juraj H?ska > > When I have: > {code} > ScreenshotEntry propertyEntry = new ScreenshotEntry(); > propertyEntry.setPhase(When.ON_EVERY_ACTION); > ... > propertyReportEvent.fire(new PropertyReportEvent(propertyEntry)); > {code} > then such a screenshot is not part of the generated report. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 06:48:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 06:48:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1829) Reporting ScreenshotEntry with phase == onEveryAction is not possible In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska reassigned ARQ-1829: -------------------------------- Assignee: Juraj H?ska > Reporting ScreenshotEntry with phase == onEveryAction is not possible > --------------------------------------------------------------------- > > Key: ARQ-1829 > URL: https://issues.jboss.org/browse/ARQ-1829 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Recorder > Affects Versions: 1.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > > When I have: > {code} > ScreenshotEntry propertyEntry = new ScreenshotEntry(); > propertyEntry.setPhase(When.ON_EVERY_ACTION); > ... > propertyReportEvent.fire(new PropertyReportEvent(propertyEntry)); > {code} > then such a screenshot is not part of the generated report. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 06:48:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 30 Jul 2014 06:48:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-456) Screenshots made onEveryAction are reported as screenshots made onBefore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska reassigned ARQGRA-456: ---------------------------------- Assignee: Juraj H?ska > Screenshots made onEveryAction are reported as screenshots made onBefore > ------------------------------------------------------------------------ > > Key: ARQGRA-456 > URL: https://issues.jboss.org/browse/ARQGRA-456 > Project: Arquillian Graphene > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: screenshooter > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: 2.1.0.Alpha2 > > Attachments: wrongOnEveryAction.png > > > The problem is that {{TakeScreenshotEvent}} is always fired only with {{onBefore}}. > I need to change this phase when appropriate for {{onEveryAction}}. > Possible candidates: > * before injecting into interceptors, [here|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/ScreenshotTaker.java#L67] > * in the interceptor itself, somewhere inside this [block|https://github.com/arquillian/arquillian-graphene/blob/2.1.x/extension/screenshooter/src/main/java/org/arquillian/extension/recorder/screenshooter/browser/impl/TakeScreenshotOnEveryActionInterceptor.java#L60]. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 08:22:29 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 30 Jul 2014 08:22:29 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-457) Upgrade Tomcat version in ftest In-Reply-To: References: Message-ID: Pavol Pitonak created ARQGRA-457: ------------------------------------ Summary: Upgrade Tomcat version in ftest Key: ARQGRA-457 URL: https://issues.jboss.org/browse/ARQGRA-457 Project: Arquillian Graphene Issue Type: Enhancement Security Level: Public (Everyone can see) Components: ftest Affects Versions: 2.0.3.Final Reporter: Pavol Pitonak Module ftest downloads Tomcat distribution from Maven repository using com.googlecode.t7mp:tomcat:7.0.26. It should use official Apache's distribution from org.apache.tomcat:tomcat:7.0.55 (latest release 7.x) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 08:24:30 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 30 Jul 2014 08:24:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-457) Upgrade Tomcat version in ftest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated ARQGRA-457: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/117 > Upgrade Tomcat version in ftest > ------------------------------- > > Key: ARQGRA-457 > URL: https://issues.jboss.org/browse/ARQGRA-457 > Project: Arquillian Graphene > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: ftest > Affects Versions: 2.0.3.Final > Reporter: Pavol Pitonak > > Module ftest downloads Tomcat distribution from Maven repository using com.googlecode.t7mp:tomcat:7.0.26. > It should use official Apache's distribution from org.apache.tomcat:tomcat:7.0.55 (latest release 7.x) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 08:40:30 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 08:40:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-457) Upgrade Tomcat version in ftest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-457: ------------------------------ Fix Version/s: 2.1.0.Alpha2 > Upgrade Tomcat version in ftest > ------------------------------- > > Key: ARQGRA-457 > URL: https://issues.jboss.org/browse/ARQGRA-457 > Project: Arquillian Graphene > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: ftest > Affects Versions: 2.0.3.Final > Reporter: Pavol Pitonak > Fix For: 2.1.0.Alpha2 > > > Module ftest downloads Tomcat distribution from Maven repository using com.googlecode.t7mp:tomcat:7.0.26. > It should use official Apache's distribution from org.apache.tomcat:tomcat:7.0.55 (latest release 7.x) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 08:40:30 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 30 Jul 2014 08:40:30 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-457) Upgrade Tomcat version in ftest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-457: ------------------------------ Assignee: Pavol Pitonak > Upgrade Tomcat version in ftest > ------------------------------- > > Key: ARQGRA-457 > URL: https://issues.jboss.org/browse/ARQGRA-457 > Project: Arquillian Graphene > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: ftest > Affects Versions: 2.0.3.Final > Reporter: Pavol Pitonak > Assignee: Pavol Pitonak > Fix For: 2.1.0.Alpha2 > > > Module ftest downloads Tomcat distribution from Maven repository using com.googlecode.t7mp:tomcat:7.0.26. > It should use official Apache's distribution from org.apache.tomcat:tomcat:7.0.55 (latest release 7.x) -- This message was sent by Atlassian JIRA (v6.2.6#6264)