From issues at jboss.org Mon Feb 3 04:06:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 3 Feb 2014 04:06:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1632) Update PhantomJS Driver to 1.1.2.Final to have 1.9.7 PhantomJS binary In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1632: ----------------------------- Fix Version/s: drone_1.2.3.Final > Update PhantomJS Driver to 1.1.2.Final to have 1.9.7 PhantomJS binary > --------------------------------------------------------------------- > > Key: ARQ-1632 > URL: https://issues.jboss.org/browse/ARQ-1632 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.2.Final > Reporter: Karel Piwko > Fix For: drone_1.2.3.Final > > > Update to latest available phantomjs driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 04:06:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 3 Feb 2014 04:06:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1632) Update PhantomJS Driver to 1.1.2.Final to have 1.9.7 PhantomJS binary In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko resolved ARQ-1632. ------------------------------ Resolution: Done > Update PhantomJS Driver to 1.1.2.Final to have 1.9.7 PhantomJS binary > --------------------------------------------------------------------- > > Key: ARQ-1632 > URL: https://issues.jboss.org/browse/ARQ-1632 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.2.Final > Reporter: Karel Piwko > Fix For: drone_1.2.3.Final > > > Update to latest available phantomjs driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 04:10:28 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 3 Feb 2014 04:10:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1632) Update PhantomJS Driver to 1.1.2.Final to have 1.9.7 PhantomJS binary In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko closed ARQ-1632. ---------------------------- Assignee: Karel Piwko Fixed in https://github.com/arquillian/arquillian-extension-drone/commit/0080d834329975d9fbc0e2ec15f338e238777fcc > Update PhantomJS Driver to 1.1.2.Final to have 1.9.7 PhantomJS binary > --------------------------------------------------------------------- > > Key: ARQ-1632 > URL: https://issues.jboss.org/browse/ARQ-1632 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.2.Final > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: drone_1.2.3.Final > > > Update to latest available phantomjs driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 08:24:28 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 3 Feb 2014 08:24:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-412) Injection @Drone WebDriver into fragment doesn't respect qualifier annotation on fragment field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-412: ------------------------------ Fix Version/s: 2.0-Tracking (was: 2.0.1.Final) > Injection @Drone WebDriver into fragment doesn't respect qualifier annotation on fragment field > ----------------------------------------------------------------------------------------------- > > Key: ARQGRA-412 > URL: https://issues.jboss.org/browse/ARQGRA-412 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.0.Final > Reporter: Jan Dosoudil > Fix For: 2.0-Tracking > > > It's related to ARQGRA-393, but I think it's another problem. > {code:title=Sample testcase} > @RunWith(Arquillian.class) > @WarpTest > @RunAsClient > class Test { > @Drone @First > private WebDriver browser1; > @FindBy(id="id") @First > private Fragment fragment1; > @Drone @Second > private WebDriver browser2; > @FindBy(id="id") @Second > private Fragment fragment2; > } > {code} > {code:title=Sample fragment} > class Fragment { > @Drone > private WebDriver browser; > } > {code} > {code:title=Exception} > Caused by: java.lang.IllegalArgumentException: Retrieved a null from context, which is not a valid Drone browser object > at org.jboss.arquillian.drone.impl.Validate.notNull(Validate.java:42) > at org.jboss.arquillian.drone.impl.DroneTestEnricher.getDroneInstance(DroneTestEnricher.java:107) > at org.jboss.arquillian.drone.impl.DroneTestEnricher.enrich(DroneTestEnricher.java:72) > at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:70) > at org.jboss.arquillian.graphene.enricher.PageFragmentEnricher.createPageFragment(PageFragmentEnricher.java:156) > ... 71 more > {code} > If I removed @First annotations at all, It seems to run OK but in fragment annotated with @Second is injected default WebDriver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 08:24:28 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 3 Feb 2014 08:24:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-407) Document WebDriverWait API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-407: ------------------------------ Fix Version/s: 2.0-Tracking (was: 2.0.1.Final) > Document WebDriverWait API > -------------------------- > > Key: ARQGRA-407 > URL: https://issues.jboss.org/browse/ARQGRA-407 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.0.Final > Reporter: Luk?? Fry? > Priority: Critical > Fix For: 2.0-Tracking > > > https://github.com/arquillian/arquillian-graphene/blob/2.0.0.Final/api/src/main/java/org/jboss/arquillian/graphene/wait/WebDriverWait.java#L45 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 08:24:28 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 3 Feb 2014 08:24:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-395) Graphene.guardAjax() doesn't work correctly in IE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-395: ------------------------------ Fix Version/s: 2.0-Tracking (was: 2.0.1.Final) > Graphene.guardAjax() doesn't work correctly in IE > ------------------------------------------------- > > Key: ARQGRA-395 > URL: https://issues.jboss.org/browse/ARQGRA-395 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.0.CR2 > Environment: IE 7, 8, 9 > Reporter: Jan Dosoudil > Assignee: Luk?? Fry? > Fix For: 2.0-Tracking > > > I have jsf page h:commandButton with f:ajax. Testing with Graphene.guardAjax(button).click(); works with Firefox, htmlUnit, phantomjs but doesn't with Internet Explorer (7, 8, 9). Internet explorer calls onclick function but without return false which causes full page submit. > button.click() works ok. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 08:24:28 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 3 Feb 2014 08:24:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-353) Integration tests fail on Opera with Graphene Alpha5, Selenium 2.35 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-353: ------------------------------ Fix Version/s: 2.0-Tracking (was: 2.0.1.Final) > Integration tests fail on Opera with Graphene Alpha5, Selenium 2.35 > ------------------------------------------------------------------- > > Key: ARQGRA-353 > URL: https://issues.jboss.org/browse/ARQGRA-353 > Project: Arquillian Graphene > Issue Type: Enhancement > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Priority: Optional > Labels: padawan > Fix For: 2.0-Tracking > > > {code} > Results : > Failed tests: testUnstable(org.jboss.arquillian.graphene.ftest.javascript.EnrichmentTestCase): Can't invoke unstable javascript extension: Can't invoke the javacript org.jboss.arquillian.graphene.ftest.javascript.EnrichmentTestCase$Unstable#simple() > testIncorrectInstallation(org.jboss.arquillian.graphene.ftest.page.extension.PageExtensionTestCase): Expected exception: java.lang.IllegalStateException > testJQuerySelectorCallingFindByDirectly(org.jboss.arquillian.graphene.ftest.page.extension.JQuerySelectorsPageExtensionTestCase): expected:<[h]1> but was:<[H]1> > testFindByOnWebElement(org.jboss.arquillian.graphene.ftest.page.extension.JQuerySelectorsPageExtensionTestCase): expected:<[h]1> but was:<[H]1> > testFindByOnListOfWebElement(org.jboss.arquillian.graphene.ftest.page.extension.JQuerySelectorsPageExtensionTestCase): expected:<[h]1> but was:<[H]1> > Tests in error: > testScreenMethods(org.jboss.arquillian.graphene.ftest.javascript.EnrichmentTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.ftest.javascript.EnrichmentTestCase$Screen#getHeight() > test(org.jboss.arquillian.graphene.ftest.javascript.TestCustomJSInterface): Can't invoke the javacript org.jboss.arquillian.graphene.page.document.Document#getTitle() > testWithSources(org.jboss.arquillian.graphene.ftest.javascript.JavaScriptPageExtensionTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.ftest.javascript.JavaScriptPageExtensionTestCase$HelloWorld#hello() > testWithInterfaceDependencies(org.jboss.arquillian.graphene.ftest.javascript.JavaScriptPageExtensionTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.ftest.javascript.JavaScriptPageExtensionTestCase$HelloWorld2#hello() > testStelenessAndJavascriptOnWebDriver(org.jboss.arquillian.graphene.ftest.webdriver.FindElementTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.ftest.webdriver.FindElementTestCase$JQueryInstallator#install() > testStelenessAndJavascriptOnWebElement(org.jboss.arquillian.graphene.ftest.webdriver.FindElementTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.ftest.webdriver.FindElementTestCase$JQueryInstallator#install() > testGuardHttp(org.jboss.arquillian.graphene.ftest.parallel.TestGrapheneUtilitiesParalelly): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardXhr(org.jboss.arquillian.graphene.ftest.parallel.TestGrapheneUtilitiesParalelly): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardHttp(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardAjax(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardDelayedAjax(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardDelayedAjaxProcessing(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardDelayedTrigerringAndProcessing(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardDelayedAjaxProcessingWithCodeArgument(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardAjaxWithRelocation(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testGuardHttpFailure(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Unexpected exception, expected but was > testGuardNoRequestFailure(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Unexpected exception, expected but was > testGuardAjaxFailure(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Unexpected exception, expected but was > testDelayedGuardNoRequest(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Unexpected exception, expected but was > testGuardNoRequest(org.jboss.arquillian.graphene.ftest.guard.GuardsTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#clearRequestDone() > testXhr(org.jboss.arquillian.graphene.ftest.guard.RequestGuardTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#getRequestType() > testHttp(org.jboss.arquillian.graphene.ftest.guard.RequestGuardTestCase): Can't invoke the javacript org.jboss.arquillian.graphene.guard.RequestGuardImpl#getRequestType() > testCorrectInstallation(org.jboss.arquillian.graphene.ftest.page.extension.PageExtensionTestCase): com.opera.core.systems.scope.exceptions.ResponseNotReceivedException: No response in a timely fashion > testDeletion(org.jboss.arquillian.graphene.ftest.enricher.TestHandlingOfStaleElements): com.sun.proxy.$Proxy21 cannot be cast to com.opera.core.systems.OperaWebElement > testReplacement(org.jboss.arquillian.graphene.ftest.enricher.TestHandlingOfStaleElements): com.sun.proxy.$Proxy21 cannot be cast to com.opera.core.systems.OperaWebElement > testOneWithJavascript(org.jboss.arquillian.graphene.ftest.enricher.TestGrapheneElement): Can't invoke the javacript org.jboss.arquillian.graphene.ftest.enricher.TestGrapheneElement$TestJavascript#getInnerHtml() > testListWithJavascript(org.jboss.arquillian.graphene.ftest.enricher.TestGrapheneElement): Can't invoke the javacript org.jboss.arquillian.graphene.ftest.enricher.TestGrapheneElement$TestJavascript#getInnerHtml() > Tests run: 271, Failures: 5, Errors: 27, Skipped: 0 > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 4 08:14:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 4 Feb 2014 08:14:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: Juraj H?ska created ARQ-1634: -------------------------------- Summary: Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false Key: ARQ-1634 URL: https://issues.jboss.org/browse/ARQ-1634 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: 1.1.2.Final Environment: Drone 1.2.3.Final Reporter: Juraj H?ska {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 4 08:14:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 4 Feb 2014 08:14:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQ-1634: ----------------------------- Assignee: Juraj H?ska > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: 1.1.2.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 4 08:14:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 4 Feb 2014 08:14:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1634 started by Juraj H?ska. > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: 1.1.2.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 4 08:56:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 4 Feb 2014 08:56:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQ-1634: ----------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/33 Linkin PR with fix. > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: 1.1.2.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 4 08:56:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 4 Feb 2014 08:56:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQ-1634: ----------------------------- Assignee: (was: Juraj H?ska) > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: 1.1.2.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:30:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Wed, 5 Feb 2014 11:30:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1634: ----------------------------- Fix Version/s: drone_1.2.4.Final > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: 1.1.2.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Fix For: drone_1.2.4.Final > > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:30:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Wed, 5 Feb 2014 11:30:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1634: ----------------------------- Affects Version/s: drone_1.2.2.Final (was: 1.1.2.Final) > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.2.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Fix For: drone_1.2.4.Final > > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:30:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Wed, 5 Feb 2014 11:30:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1634: ----------------------------- Affects Version/s: drone_1.2.3.Final (was: drone_1.2.2.Final) > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Fix For: drone_1.2.4.Final > > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:32:28 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Wed, 5 Feb 2014 11:32:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1634: ----------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Juraj H?ska Resolution: Done Pushed upstream in https://github.com/arquillian/arquillian-extension-drone/commit/bf5618845c122809a832f2edbd695bf34e81a5fb > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: drone_1.2.4.Final > > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:32:28 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Wed, 5 Feb 2014 11:32:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12941600#comment-12941600 ] Karel Piwko commented on ARQ-1634: ---------------------------------- Thanks [~jhuska] > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: drone_1.2.4.Final > > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 6 05:12:28 2014 From: issues at jboss.org (Valtoni Boaventura (JIRA)) Date: Thu, 6 Feb 2014 05:12:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1565) "Falied to connect" with WebLogic included libraries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12941778#comment-12941778 ] Valtoni Boaventura commented on ARQ-1565: ----------------------------------------- Vineet: removing {code:xml} {code} The errors wasn't occurr. > "Falied to connect" with WebLogic included libraries > ---------------------------------------------------- > > Key: ARQ-1565 > URL: https://issues.jboss.org/browse/ARQ-1565 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: WebLogic Containers > Affects Versions: wls_1.0.0.Alpha2 > Environment: windows 7 64bits > Reporter: Valtoni Boaventura > Assignee: Vineet Reynolds > > In Wls 10.3.5, project working 100% without weblogic libraries in eclipse . > Version: Kepler Release > Build id: 20130614-0229 > With weblogic libraries, this connection error occur: > {code} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Failed to obtain a connection to the MBean Server. > at org.jboss.arquillian.container.wls.WebLogicJMXClient.createConnection(WebLogicJMXClient.java:485) > at org.jboss.arquillian.container.wls.WebLogicJMXClient.(WebLogicJMXClient.java:290) > at org.jboss.arquillian.container.wls.remote_10_3.WebLogicContainer.start(WebLogicContainer.java:58) > 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:256) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:167) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:68) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:78) > 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:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:68) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:69) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:684) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:391) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.io.IOException > at weblogic.management.remote.common.ClientProviderBase.makeConnection(ClientProviderBase.java:196) > at weblogic.management.remote.common.ClientProviderBase.newJMXConnector(ClientProviderBase.java:84) > at javax.management.remote.JMXConnectorFactory.newJMXConnector(JMXConnectorFactory.java:338) > at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:247) > at org.jboss.arquillian.container.wls.WebLogicJMXClient.createConnection(WebLogicJMXClient.java:480) > at org.jboss.arquillian.container.wls.WebLogicJMXClient.(WebLogicJMXClient.java:290) > at org.jboss.arquillian.container.wls.remote_10_3.WebLogicContainer.start(WebLogicContainer.java:58) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > ... 1 more > Caused by: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: > java.io.EOFException] > at weblogic.jrmp.Context.lookup(Context.java:189) > at weblogic.jrmp.Context.lookup(Context.java:195) > at javax.naming.InitialContext.lookup(InitialContext.java:392) > at weblogic.management.remote.common.ClientProviderBase.makeConnection(ClientProviderBase.java:179) > ... 67 more > Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: > java.io.EOFException > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:286) > at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184) > at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322) > at weblogic.jrmp.BaseRemoteRef.invoke(BaseRemoteRef.java:221) > at weblogic.jrmp.RegistryImpl_Stub.lookup(Unknown Source) > at weblogic.jrmp.Context.lookup(Context.java:185) > at weblogic.jrmp.Context.lookup(Context.java:195) > at javax.naming.InitialContext.lookup(InitialContext.java:392) > at weblogic.management.remote.common.ClientProviderBase.makeConnection(ClientProviderBase.java:179) > at weblogic.management.remote.common.ClientProviderBase.newJMXConnector(ClientProviderBase.java:84) > at javax.management.remote.JMXConnectorFactory.newJMXConnector(JMXConnectorFactory.java:338) > at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:247) > at org.jboss.arquillian.container.wls.WebLogicJMXClient.createConnection(WebLogicJMXClient.java:480) > at org.jboss.arquillian.container.wls.WebLogicJMXClient.(WebLogicJMXClient.java:290) > at org.jboss.arquillian.container.wls.remote_10_3.WebLogicContainer.start(WebLogicContainer.java:58) > 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:256) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:167) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:68) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:78) > 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:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:68) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:69) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:684) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:391) > ... 1 more > Caused by: java.io.EOFException > at java.io.DataInputStream.readByte(DataInputStream.java:250) > at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:228) > ... 75 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 6 06:02:28 2014 From: issues at jboss.org (Daniel Wamara (JIRA)) Date: Thu, 6 Feb 2014 06:02:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-184) NPE in o.j.aop.Dispatcher.invoke:117 - ARQ Alpha2 + remote-50 + as-client 5.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12941792#comment-12941792 ] Daniel Wamara commented on ARQ-184: ----------------------------------- AS7-2616 is not really a solution for this. I also disabled the authentication and still got the same error, it could be that it is a problem pertaining to EAP 5.0.1 > NPE in o.j.aop.Dispatcher.invoke:117 - ARQ Alpha2 + remote-50 + as-client 5.0.1 > ------------------------------------------------------------------------------- > > Key: ARQ-184 > URL: https://issues.jboss.org/browse/ARQ-184 > Project: Arquillian > Issue Type: Bug > Environment: ARQ Alpha2 + remote-50 + as-client 5.0.1 + EAP 5.0.1 > Reporter: Ondrej Zizka > Fix For: jbossas_1.0.0.Final > > Attachments: EapDeployPerfArquillian.zip > > > STR: > 1) Download the project attached, > 2) Run EAP 5.0.1 default, but I think the request doesn't even get sent. > 3) mvn clean install (profile is self-enabled), > 4) You'll get a NPE: > org.jboss.arquillian.impl.event.FiredEventException: org.jboss.arquillian.spi.LifecycleException: Could not connect to container > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:68) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:62) > at org.jboss.arquillian.junit.Arquillian.(Arquillian.java:71) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) > at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) > at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) > at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) > at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) > at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) > at org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) > at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) > at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) > at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) > at org.apache.maven.surefire.Surefire.run(Surefire.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) > at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) > Caused by: org.jboss.arquillian.spi.LifecycleException: Could not connect to container > at org.jboss.arquillian.jbossas.remote50.JBossASRemoteContainer.start(JBossASRemoteContainer.java:89) > at org.jboss.arquillian.impl.handler.ContainerStarter.callback(ContainerStarter.java:52) > at org.jboss.arquillian.impl.handler.ContainerStarter.callback(ContainerStarter.java:41) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > ... 24 more > Caused by: java.lang.NullPointerException > at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:117) > at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) > at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:210) > at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897) > at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:768) > at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:721) > at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548) > at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) > at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:206) > at org.jboss.remoting.Client.invoke(Client.java:1708) > at org.jboss.remoting.Client.invoke(Client.java:612) > at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) > at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) > at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) > at AOPProxy$1.loadProfile(AOPProxy$1.java) > at org.jboss.arquillian.jbossas.remote50.JBossASRemoteContainer.initDeploymentManager(JBossASRemoteContainer.java:222) > at org.jboss.arquillian.jbossas.remote50.JBossASRemoteContainer.start(JBossASRemoteContainer.java:85) > at org.jboss.arquillian.impl.handler.ContainerStarter.callback(ContainerStarter.java:52) > at org.jboss.arquillian.impl.handler.ContainerStarter.callback(ContainerStarter.java:41) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:62) > at org.jboss.arquillian.junit.Arquillian.(Arquillian.java:71) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) > at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) > at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) > at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) > at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) > at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) > at org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) > at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) > at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) > at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) > at org.apache.maven.surefire.Surefire.run(Surefire.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) > at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) > at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) > at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) > at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) > at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) > at AOPProxy$1.loadProfile(AOPProxy$1.java) > at org.jboss.arquillian.jbossas.remote50.JBossASRemoteContainer.initDeploymentManager(JBossASRemoteContainer.java:222) > at org.jboss.arquillian.jbossas.remote50.JBossASRemoteContainer.start(JBossASRemoteContainer.java:85) > ... 27 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 7 07:18:28 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 7 Feb 2014 07:18:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1635) Wrong SPI implementation registered for Standalone module In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-1635: ----------------------------------- Summary: Wrong SPI implementation registered for Standalone module Key: ARQ-1635 URL: https://issues.jboss.org/browse/ARQ-1635 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Spock TestRunner Affects Versions: spock_1.0.0.Beta2 Reporter: Bartosz Majsak Assignee: Bartosz Majsak Fix For: spock_1.0.0.next unable to run any tests, all resulted in a ClassNotFoundException: Caused by: java.lang.ClassNotFoundException: org.jboss.arquillian.junit.standalone.SpockStandaloneExtension Happens every time the runner tries to initialize services. The SpockStandaloneExtension class is on the classpath, but looks like it is in a different package: org.jboss.arquillian.spock.standalone.SpockStandaloneExtension -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 7 07:26:28 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 7 Feb 2014 07:26:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1635) Wrong SPI implementation registered for Standalone module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak resolved ARQ-1635. --------------------------------- Resolution: Done Fixed and [pushed upstream|https://github.com/arquillian/arquillian-testrunner-spock/commit/f40ab7a37c20ce331229468a09cd4b1c059d5889]. > Wrong SPI implementation registered for Standalone module > --------------------------------------------------------- > > Key: ARQ-1635 > URL: https://issues.jboss.org/browse/ARQ-1635 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Spock TestRunner > Affects Versions: spock_1.0.0.Beta2 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: spock_1.0.0.next > > > unable to run any tests, all resulted in a ClassNotFoundException: > Caused by: java.lang.ClassNotFoundException: org.jboss.arquillian.junit.standalone.SpockStandaloneExtension > Happens every time the runner tries to initialize services. The SpockStandaloneExtension class is on the classpath, but looks like it is in a different package: org.jboss.arquillian.spock.standalone.SpockStandaloneExtension -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 06:13:28 2014 From: issues at jboss.org (Abhijit Vikash (JIRA)) Date: Mon, 10 Feb 2014 06:13:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1636) org.jboss.shrinkwrap.resolver.api.NoResolvedResultException In-Reply-To: References: Message-ID: Abhijit Vikash created ARQ-1636: ----------------------------------- Summary: org.jboss.shrinkwrap.resolver.api.NoResolvedResultException Key: ARQ-1636 URL: https://issues.jboss.org/browse/ARQ-1636 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Environment: Jboss EAP 6.5, ShrinkWrap, Arquillian, Teiid Reporter: Abhijit Vikash Priority: Critical Feb 10, 2014 4:01:18 PM org.jboss.shrinkwrap.resolver.impl.maven.logging.LogRepositoryListener artifactDescriptorInvalid WARNING: Invalid artifact descriptor for org.jboss.teiid:teiid-client:jar:8.2.0.Final: 4 problems were encountered while building the effective model for org.jboss.teiid:teiid-client:8.2.0.Final [ERROR] Invalid packaging for parent POM org.jboss.teiid:teiid-parent:8.2.0.Final, must be "pom" but is "jar" @ org.jboss.teiid:teiid-parent:8.2.0.Final [ERROR] 'dependencies.dependency.version' for org.jboss.teiid:teiid-common-core:jar is missing. @ [ERROR] 'dependencies.dependency.version' for org.jboss.teiid:teiid-common-core:test-jar is missing. @ [ERROR] 'dependencies.dependency.version' for org.jboss.modules:jboss-modules:jar is missing. @ org.jboss.shrinkwrap.resolver.api.NoResolvedResultException: Unable to collect/resolve dependency tree for a resulution due to: The following artifacts could not be resolved: org.hibernate:hibernate-core:jar:4.2.0.Final-redhat-1, org.hibernate:hibernate-entitymanager:jar:4.2.0.Final-redhat-1: Could not transfer artifact org.hibernate:hibernate-core:jar:4.2.0.Final-redhat-1 from/to jboss-ip-repository (http://maven.repository.redhat.com/techpreview/ip6/6.0.0.Beta/maven-repository/): No connector available to access repository jboss-ip-repository (http://maven.repository.redhat.com/techpreview/ip6/6.0.0.Beta/maven-repository/) of type default using the available factories WagonRepositoryConnectorFactory, caused by: No connector available to access repository jboss-ip-repository (http://maven.repository.redhat.com/techpreview/ip6/6.0.0.Beta/maven-repository/) of type default using the available factories WagonRepositoryConnectorFactory at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.wrapException(MavenWorkingSessionImpl.java:497) at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:262) at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:67) at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:49) at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:38) at com.nielsen.engineering.mediaworks.dataservices.services.test.ejb.PanelInfoServiceBeanTest.createArchive(PanelInfoServiceBeanTest.java:76) 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.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:156) at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generateDeployment(AnnotationDeploymentScenarioGenerator.java:94) at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generate(AnnotationDeploymentScenarioGenerator.java:57) at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:79) 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:100) 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.createClassContext(TestContextHandler.java:75) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java: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.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.beforeClass(EventTestRunnerAdaptor.java:80) at org.jboss.arquillian.testng.Arquillian.arquillianBeforeClass(Arquillian.java:103) 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130) at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:173) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:105) at org.testng.TestRunner.runWorkers(TestRunner.java:1125) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274) at org.testng.SuiteRunner.run(SuiteRunner.java:223) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:995) at org.testng.TestNG.runSuitesLocally(TestNG.java:920) at org.testng.TestNG.run(TestNG.java:856) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:72) at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:88) at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:101) 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 $Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) 2014-02-10 16:01:19,285 ERROR [connection:105].handleException(): JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host Tests run: 15, Failures: 1, Errors: 0, Skipped: 8, Time elapsed: 66.118 sec <<< FAILURE! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 06:17:28 2014 From: issues at jboss.org (Abhijit Vikash (JIRA)) Date: Mon, 10 Feb 2014 06:17:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1636) org.jboss.shrinkwrap.resolver.api.NoResolvedResultException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12942937#comment-12942937 ] Abhijit Vikash commented on ARQ-1636: ------------------------------------- I am using ShrinkWrap to package my project but I am getting the above there appears to be some conflict with teiid dependencies that i am using in my parent pom : org.jboss.teiid teiid-parent pom compile 8.2.0.Final org.jboss.teiid teiid-client 8.2.0.Final compile jar > org.jboss.shrinkwrap.resolver.api.NoResolvedResultException > ----------------------------------------------------------- > > Key: ARQ-1636 > URL: https://issues.jboss.org/browse/ARQ-1636 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: Jboss EAP 6.5, ShrinkWrap, Arquillian, Teiid > Reporter: Abhijit Vikash > Priority: Critical > > Feb 10, 2014 4:01:18 PM org.jboss.shrinkwrap.resolver.impl.maven.logging.LogRepositoryListener artifactDescriptorInvalid > WARNING: Invalid artifact descriptor for org.jboss.teiid:teiid-client:jar:8.2.0.Final: 4 problems were encountered while building the effective model for org.jboss.teiid:teiid-client:8.2.0.Final > [ERROR] Invalid packaging for parent POM org.jboss.teiid:teiid-parent:8.2.0.Final, must be "pom" but is "jar" @ org.jboss.teiid:teiid-parent:8.2.0.Final > [ERROR] 'dependencies.dependency.version' for org.jboss.teiid:teiid-common-core:jar is missing. @ > [ERROR] 'dependencies.dependency.version' for org.jboss.teiid:teiid-common-core:test-jar is missing. @ > [ERROR] 'dependencies.dependency.version' for org.jboss.modules:jboss-modules:jar is missing. @ > org.jboss.shrinkwrap.resolver.api.NoResolvedResultException: Unable to collect/resolve dependency tree for a resulution due to: The following artifacts could not be resolved: org.hibernate:hibernate-core:jar:4.2.0.Final-redhat-1, org.hibernate:hibernate-entitymanager:jar:4.2.0.Final-redhat-1: Could not transfer artifact org.hibernate:hibernate-core:jar:4.2.0.Final-redhat-1 from/to jboss-ip-repository (http://maven.repository.redhat.com/techpreview/ip6/6.0.0.Beta/maven-repository/): No connector available to access repository jboss-ip-repository (http://maven.repository.redhat.com/techpreview/ip6/6.0.0.Beta/maven-repository/) of type default using the available factories WagonRepositoryConnectorFactory, caused by: No connector available to access repository jboss-ip-repository (http://maven.repository.redhat.com/techpreview/ip6/6.0.0.Beta/maven-repository/) of type default using the available factories WagonRepositoryConnectorFactory > at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.wrapException(MavenWorkingSessionImpl.java:497) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:262) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:67) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:49) > at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:38) > at com.nielsen.engineering.mediaworks.dataservices.services.test.ejb.PanelInfoServiceBeanTest.createArchive(PanelInfoServiceBeanTest.java:76) > 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.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:156) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generateDeployment(AnnotationDeploymentScenarioGenerator.java:94) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generate(AnnotationDeploymentScenarioGenerator.java:57) > at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:79) > 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:100) > 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.createClassContext(TestContextHandler.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java: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.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.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.testng.Arquillian.arquillianBeforeClass(Arquillian.java:103) > 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130) > at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:173) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:105) > at org.testng.TestRunner.runWorkers(TestRunner.java:1125) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274) > at org.testng.SuiteRunner.run(SuiteRunner.java:223) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:995) > at org.testng.TestNG.runSuitesLocally(TestNG.java:920) > at org.testng.TestNG.run(TestNG.java:856) > at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:72) > at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:88) > at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:101) > 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 $Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > 2014-02-10 16:01:19,285 ERROR [connection:105].handleException(): JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host > Tests run: 15, Failures: 1, Errors: 0, Skipped: 8, Time elapsed: 66.118 sec <<< FAILURE! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 08:43:28 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 10 Feb 2014 08:43:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-420) Port unified screenshooter implementation for Graphene into Graphene project itself In-Reply-To: References: Message-ID: Juraj H?ska created ARQGRA-420: ---------------------------------- Summary: 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 Components: api, build, core Affects Versions: 2.0.1.Final Reporter: Juraj H?ska 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 08:43:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 10 Feb 2014 08:43:29 -0500 (EST) 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 ] Juraj H?ska updated ARQGRA-420: ------------------------------- Description: 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. was: 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. > 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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 10:59:29 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 10 Feb 2014 10:59:29 -0500 (EST) 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 ] Stefan Miklosovic reassigned ARQGRA-420: ---------------------------------------- Assignee: Stefan Miklosovic > 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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 11:15:30 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 10 Feb 2014 11:15:30 -0500 (EST) 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-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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 17:01:28 2014 From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=) Date: Mon, 10 Feb 2014 17:01:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12943245#comment-12943245 ] P?tr Andreev commented on ARQ-1618: ----------------------------------- Hi guys any update on the issue? > Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1618 > URL: https://issues.jboss.org/browse/ARQ-1618 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Environment: Win7,CentOS > Jboss7, Wildfly8 > Reporter: P?tr Andreev > Priority: Minor > > The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. > As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 23:05:28 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 10 Feb 2014 23:05:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1635) Wrong SPI implementation registered for Standalone module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1635: ------------------------------- Fix Version/s: spock_1.0.0.Beta3 (was: spock_1.0.0.next) > Wrong SPI implementation registered for Standalone module > --------------------------------------------------------- > > Key: ARQ-1635 > URL: https://issues.jboss.org/browse/ARQ-1635 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Spock TestRunner > Affects Versions: spock_1.0.0.Beta2 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: spock_1.0.0.Beta3 > > > unable to run any tests, all resulted in a ClassNotFoundException: > Caused by: java.lang.ClassNotFoundException: org.jboss.arquillian.junit.standalone.SpockStandaloneExtension > Happens every time the runner tries to initialize services. The SpockStandaloneExtension class is on the classpath, but looks like it is in a different package: org.jboss.arquillian.spock.standalone.SpockStandaloneExtension -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 23:55:28 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 10 Feb 2014 23:55:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1635) Wrong SPI implementation registered for Standalone module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1635. ------------------------------ > Wrong SPI implementation registered for Standalone module > --------------------------------------------------------- > > Key: ARQ-1635 > URL: https://issues.jboss.org/browse/ARQ-1635 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Spock TestRunner > Affects Versions: spock_1.0.0.Beta2 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: spock_1.0.0.Beta3 > > > unable to run any tests, all resulted in a ClassNotFoundException: > Caused by: java.lang.ClassNotFoundException: org.jboss.arquillian.junit.standalone.SpockStandaloneExtension > Happens every time the runner tries to initialize services. The SpockStandaloneExtension class is on the classpath, but looks like it is in a different package: org.jboss.arquillian.spock.standalone.SpockStandaloneExtension -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 11 00:03:28 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 11 Feb 2014 00:03:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1637) Gracefully deactivate context when creation fails In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1637: ---------------------------------- Summary: Gracefully deactivate context when creation fails Key: ARQ-1637 URL: https://issues.jboss.org/browse/ARQ-1637 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Weld Containers Affects Versions: weld_1.0.0.CR7 Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: weld_1.0.0.CR8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 11 00:05:28 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 11 Feb 2014 00:05:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1637) Gracefully deactivate context when creation fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1637: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-container-weld/pull/17/ > Gracefully deactivate context when creation fails > ------------------------------------------------- > > Key: ARQ-1637 > URL: https://issues.jboss.org/browse/ARQ-1637 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld Containers > Affects Versions: weld_1.0.0.CR7 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: weld_1.0.0.CR8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 11 00:07:28 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 11 Feb 2014 00:07:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1448) Weld embedded container - add CDI.current() support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1448: ------------------------------- Fix Version/s: weld_1.0.0.CR8 (was: weld_1.0.0.Final) > Weld embedded container - add CDI.current() support > --------------------------------------------------- > > Key: ARQ-1448 > URL: https://issues.jboss.org/browse/ARQ-1448 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Weld Containers > Affects Versions: weld_1.0.0.CR7 > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: weld_1.0.0.CR8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 11 00:07:28 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 11 Feb 2014 00:07:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1637) Gracefully deactivate context when creation fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1637: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Gracefully deactivate context when creation fails > ------------------------------------------------- > > Key: ARQ-1637 > URL: https://issues.jboss.org/browse/ARQ-1637 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld Containers > Affects Versions: weld_1.0.0.CR7 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: weld_1.0.0.CR8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 11 00:15:29 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 11 Feb 2014 00:15:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1637) Gracefully deactivate context when creation fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1637. ------------------------------ > Gracefully deactivate context when creation fails > ------------------------------------------------- > > Key: ARQ-1637 > URL: https://issues.jboss.org/browse/ARQ-1637 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld Containers > Affects Versions: weld_1.0.0.CR7 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: weld_1.0.0.CR8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 11 00:15:30 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 11 Feb 2014 00:15:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1448) Weld embedded container - add CDI.current() support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1448. ------------------------------ > Weld embedded container - add CDI.current() support > --------------------------------------------------- > > Key: ARQ-1448 > URL: https://issues.jboss.org/browse/ARQ-1448 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Weld Containers > Affects Versions: weld_1.0.0.CR7 > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: weld_1.0.0.CR8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 11 08:47:29 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 11 Feb 2014 08:47:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1496) Add a Tomcat 8 embedded container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12943438#comment-12943438 ] Martin Kouba commented on ARQ-1496: ----------------------------------- The signature of {{org.apache.catalina.util.ContextName}} constructor the container is using changed as well. > Add a Tomcat 8 embedded container > --------------------------------- > > Key: ARQ-1496 > URL: https://issues.jboss.org/browse/ARQ-1496 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Martin Kouba > Assignee: Martin Kouba > > {{arquillian-tomcat-embedded-7}} is not compatible with Tomcat 8 due to {{org.apache.catalina.startup.HostConfig}} does not declare {{appBase()}} method anymore. It seems {{host.getAppBaseFile()}} should be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 12 09:11:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Wed, 12 Feb 2014 09:11:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1638) Chrome driver options are not wrapped into ChromeOptions object In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1638: -------------------------------- Summary: Chrome driver options are not wrapped into ChromeOptions object Key: ARQ-1638 URL: https://issues.jboss.org/browse/ARQ-1638 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: drone_1.2.3.Final Reporter: Karel Piwko Priority: Critical Fix For: drone_1.2.4.Final Latest ChromeDriver requires capabilities to be set in ChromeOptions object. Hence passing stuff like 'binary' from arquillian.properties does not work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 05:45:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Thu, 13 Feb 2014 05:45:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1639) Enable UnusedImports in checkstyle rules In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1639: -------------------------------- Summary: Enable UnusedImports in checkstyle rules Key: ARQ-1639 URL: https://issues.jboss.org/browse/ARQ-1639 Project: Arquillian Issue Type: Task Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: drone_1.2.3.Final Reporter: Karel Piwko Checkstyle now supports scanning JavaDoc for imports. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 07:03:28 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 13 Feb 2014 07:03:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-421) Graphene Interceptors: allow logging of invoked intercepted methods including interceptor chain In-Reply-To: References: Message-ID: Luk?? Fry? created ARQGRA-421: --------------------------------- Summary: Graphene Interceptors: allow logging of invoked intercepted methods including interceptor chain Key: ARQGRA-421 URL: https://issues.jboss.org/browse/ARQGRA-421 Project: Arquillian Graphene Issue Type: Enhancement Reporter: Luk?? Fry? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 08:15:29 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Thu, 13 Feb 2014 08:15:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko reopened ARQ-1634: ------------------------------ [~jhuska] can you please rewrite a test in order to respect -Dbrowser=${browser} when testing. Currently, test spawns Firefox even if chrome is set. Also, it breaks test execution for headless machines and matrix execution. > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: drone_1.2.4.Final > > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 09:09:31 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Thu, 13 Feb 2014 09:09:31 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1638) Chrome driver options are not wrapped into ChromeOptions object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1638: ----------------------------- Forum Reference: https://community.jboss.org/message/857510 > Chrome driver options are not wrapped into ChromeOptions object > --------------------------------------------------------------- > > Key: ARQ-1638 > URL: https://issues.jboss.org/browse/ARQ-1638 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Karel Piwko > Priority: Critical > Fix For: drone_1.2.4.Final > > > Latest ChromeDriver requires capabilities to be set in ChromeOptions object. > Hence passing stuff like 'binary' from arquillian.properties does not work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 14:15:29 2014 From: issues at jboss.org (Jens Schauder (JIRA)) Date: Thu, 13 Feb 2014 14:15:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1640) Dependencies can't be loaded with gradle 1.10 due to unresolved properties in pom In-Reply-To: References: Message-ID: Jens Schauder created ARQ-1640: ---------------------------------- Summary: Dependencies can't be loaded with gradle 1.10 due to unresolved properties in pom Key: ARQ-1640 URL: https://issues.jboss.org/browse/ARQ-1640 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Weld Containers Affects Versions: 1.0.0.CR7 Reporter: Jens Schauder I'm trying to get Arquillian to work in my current project. We use Gradle as the build tool. When adding the embedded weld container as a dependency: testCompile "org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR7" I get the following error in my gradle build FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':guiTests:testCompile'. > Could not resolve org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR7. Required by: de.volkswagen.mbx:guiTests:0.1 > Could not parse POM http:///org/jboss/arquillian/container/arquillian-weld-ee- embedded-1.1/1.0.0.CR7/arquillian-weld-ee-embedded-1.1-1.0.0.CR7.pom > Unable to resolve version for dependency 'org.jboss.weld:weld-core:jar' * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED I did some searching and came to the conclussion that it is due to unresolved properties in the pom, e.g. ${weld-core-1_1.version} This seems to be discouraged even by Maven and doesn't work in Gradle http://forums.gradle.org/gradle/topics/handling_properties_in_maven_pom http://forums.gradle.org/gradle/topics/gradle_1_10_breaks_with_pom_files_that_reference_properties_from_the_parent_pom -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 20:27:30 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Thu, 13 Feb 2014 20:27:30 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1496) Add a Tomcat 8 embedded container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1496: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: tomcat_1.0.0.Final Resolution: Done > Add a Tomcat 8 embedded container > --------------------------------- > > Key: ARQ-1496 > URL: https://issues.jboss.org/browse/ARQ-1496 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: tomcat_1.0.0.Final > > > {{arquillian-tomcat-embedded-7}} is not compatible with Tomcat 8 due to {{org.apache.catalina.startup.HostConfig}} does not declare {{appBase()}} method anymore. It seems {{host.getAppBaseFile()}} should be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 03:29:28 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Fri, 14 Feb 2014 03:29:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1641) Tests with failed assumptions do not show up as skipped In-Reply-To: References: Message-ID: Thomas Diesler created ARQ-1641: ----------------------------------- Summary: Tests with failed assumptions do not show up as skipped Key: ARQ-1641 URL: https://issues.jboss.org/browse/ARQ-1641 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.1.2.Final Reporter: Thomas Diesler A test like this reports success instead of skipped. Occurs with managed wildfly, tomcat, karaf {code} @Test public void foo() throws Exception { Assume.assumeTrue(false); // test code that should only run when the above is true } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 09:39:29 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 14 Feb 2014 09:39:29 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1642) Arquillian should provide some utility class to manipulate IPv addresses In-Reply-To: References: Message-ID: Emmanuel Hugonnet created ARQ-1642: -------------------------------------- Summary: Arquillian should provide some utility class to manipulate IPv addresses Key: ARQ-1642 URL: https://issues.jboss.org/browse/ARQ-1642 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.1.2.Final Reporter: Emmanuel Hugonnet Arquillian should provide its own implementation to support IPv6 addresses instead of expecting each container to provide its own version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 09:41:28 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 14 Feb 2014 09:41:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1642) Arquillian should provide some utility class to manipulate IPv6 Addresses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated ARQ-1642: ----------------------------------- Summary: Arquillian should provide some utility class to manipulate IPv6 Addresses (was: Arquillian should provide some utility class to manipulate IPv addresses) > Arquillian should provide some utility class to manipulate IPv6 Addresses > ------------------------------------------------------------------------- > > Key: ARQ-1642 > URL: https://issues.jboss.org/browse/ARQ-1642 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.2.Final > Reporter: Emmanuel Hugonnet > > Arquillian should provide its own implementation to support IPv6 addresses instead of expecting each container to provide its own version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 10:11:28 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 14 Feb 2014 10:11:28 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1642) Arquillian should provide some utility class to manipulate IPv6 Addresses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated ARQ-1642: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/63 > Arquillian should provide some utility class to manipulate IPv6 Addresses > ------------------------------------------------------------------------- > > Key: ARQ-1642 > URL: https://issues.jboss.org/browse/ARQ-1642 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.2.Final > Reporter: Emmanuel Hugonnet > > Arquillian should provide its own implementation to support IPv6 addresses instead of expecting each container to provide its own version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 15 16:13:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sat, 15 Feb 2014 16:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1643) Client-side transaction handler incorrectly assumes it's needed to be invoked In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-1643: ----------------------------------- Summary: Client-side transaction handler incorrectly assumes it's needed to be invoked Key: ARQ-1643 URL: https://issues.jboss.org/browse/ARQ-1643 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Transaction Affects Versions: transaction_1.0.0.Final Reporter: Bartosz Majsak Fix For: transaction_1.0.0.next When using embedded containers such as Glassfish, client-side transaction handler kicks in and tries to handle transactions putting it into infinite loop of begin/commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 15 16:13:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sat, 15 Feb 2014 16:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1643) Client-side transaction handler incorrectly assumes it's needed to be invoked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945014#comment-12945014 ] Bartosz Majsak commented on ARQ-1643: ------------------------------------- [Related issue|https://issues.jboss.org/browse/ARQ-1473] > Client-side transaction handler incorrectly assumes it's needed to be invoked > ----------------------------------------------------------------------------- > > Key: ARQ-1643 > URL: https://issues.jboss.org/browse/ARQ-1643 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Reporter: Bartosz Majsak > Fix For: transaction_1.0.0.next > > > When using embedded containers such as Glassfish, client-side transaction handler kicks in and tries to handle transactions putting it into infinite loop of begin/commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 15 16:13:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sat, 15 Feb 2014 16:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1643) Client-side transaction handler incorrectly assumes it's needed to be invoked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak reassigned ARQ-1643: ----------------------------------- Assignee: Bartosz Majsak > Client-side transaction handler incorrectly assumes it's needed to be invoked > ----------------------------------------------------------------------------- > > Key: ARQ-1643 > URL: https://issues.jboss.org/browse/ARQ-1643 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: transaction_1.0.0.next > > > When using embedded containers such as Glassfish, client-side transaction handler kicks in and tries to handle transactions putting it into infinite loop of begin/commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 15 17:13:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sat, 15 Feb 2014 17:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1643) Client-side transaction handler incorrectly assumes it's needed to be invoked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak resolved ARQ-1643. --------------------------------- Resolution: Done Fixed and pushed upstream. > Client-side transaction handler incorrectly assumes it's needed to be invoked > ----------------------------------------------------------------------------- > > Key: ARQ-1643 > URL: https://issues.jboss.org/browse/ARQ-1643 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: transaction_1.0.0.next > > > When using embedded containers such as Glassfish, client-side transaction handler kicks in and tries to handle transactions putting it into infinite loop of begin/commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 15 17:15:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sat, 15 Feb 2014 17:15:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1618: -------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Bartosz Majsak Resolution: Done Thank you very much for your contribution. It's in upstream now. > Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1618 > URL: https://issues.jboss.org/browse/ARQ-1618 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Environment: Win7,CentOS > Jboss7, Wildfly8 > Reporter: P?tr Andreev > Assignee: Bartosz Majsak > Priority: Minor > > The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. > As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 16 02:55:47 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Sun, 16 Feb 2014 02:55:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1644) Arquillian Persistence doesn't work with embedded/Local containers In-Reply-To: References: Message-ID: Romain Manni-Bucau created ARQ-1644: --------------------------------------- Summary: Arquillian Persistence doesn't work with embedded/Local containers Key: ARQ-1644 URL: https://issues.jboss.org/browse/ARQ-1644 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha6 Reporter: Romain Manni-Bucau Assignee: Bartosz Majsak Because of the way its Extensions are written arquillien-extension-persistence doesn't work with Local containers (tested with OpenEJB, need hack like http://rmannibucau.wordpress.com/2013/09/05/arquillian-persistence-and-embedded-container-openejbdbunithsqldb-case/) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 16 02:57:47 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Sun, 16 Feb 2014 02:57:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1645) persistence doesn't support multiple datasources In-Reply-To: References: Message-ID: Romain Manni-Bucau created ARQ-1645: --------------------------------------- Summary: persistence doesn't support multiple datasources Key: ARQ-1645 URL: https://issues.jboss.org/browse/ARQ-1645 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha6 Reporter: Romain Manni-Bucau Assignee: Bartosz Majsak It is common to use multiple datsources (in fact all apps I'm working with does it) and ATM dbunit extension doesn't support multiple datsource init/asserts (UsingDataSet and ExpectedDataSet). Would be great to get a plural version of @DataSource and @XDataSet -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 16 04:05:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 16 Feb 2014 04:05:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1644) Arquillian Persistence doesn't work with embedded/Local containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1644: -------------------------------- Fix Version/s: persistence_1.0.0.next > Arquillian Persistence doesn't work with embedded/Local containers > ------------------------------------------------------------------ > > Key: ARQ-1644 > URL: https://issues.jboss.org/browse/ARQ-1644 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Romain Manni-Bucau > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > Because of the way its Extensions are written arquillien-extension-persistence doesn't work with Local containers (tested with OpenEJB, need hack like http://rmannibucau.wordpress.com/2013/09/05/arquillian-persistence-and-embedded-container-openejbdbunithsqldb-case/) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 16 04:05:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 16 Feb 2014 04:05:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1645) persistence doesn't support multiple datasources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1645: -------------------------------- Fix Version/s: persistence_1.0.0.next > persistence doesn't support multiple datasources > ------------------------------------------------ > > Key: ARQ-1645 > URL: https://issues.jboss.org/browse/ARQ-1645 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Romain Manni-Bucau > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > It is common to use multiple datsources (in fact all apps I'm working with does it) and ATM dbunit extension doesn't support multiple datsource init/asserts (UsingDataSet and ExpectedDataSet). > Would be great to get a plural version of @DataSource and @XDataSet -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 16 06:29:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 16 Feb 2014 06:29:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1646) Add WildFly managed container In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-1646: ----------------------------------- Summary: Add WildFly managed container Key: ARQ-1646 URL: https://issues.jboss.org/browse/ARQ-1646 Project: Arquillian Issue Type: Task Security Level: Public (Everyone can see) Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha6 Reporter: Bartosz Majsak Assignee: Bartosz Majsak Priority: Trivial Fix For: persistence_1.0.0.next -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 06:35:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 17 Feb 2014 06:35:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1618: ------------------------------- Fix Version/s: transaction_1.0.1.Final > Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1618 > URL: https://issues.jboss.org/browse/ARQ-1618 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Environment: Win7,CentOS > Jboss7, Wildfly8 > Reporter: P?tr Andreev > Assignee: Bartosz Majsak > Priority: Minor > Fix For: transaction_1.0.1.Final > > > The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. > As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 06:35:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 17 Feb 2014 06:35:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1643) Client-side transaction handler incorrectly assumes it's needed to be invoked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1643: ------------------------------- Fix Version/s: transaction_1.0.1.Final (was: transaction_1.0.0.next) > Client-side transaction handler incorrectly assumes it's needed to be invoked > ----------------------------------------------------------------------------- > > Key: ARQ-1643 > URL: https://issues.jboss.org/browse/ARQ-1643 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: transaction_1.0.1.Final > > > When using embedded containers such as Glassfish, client-side transaction handler kicks in and tries to handle transactions putting it into infinite loop of begin/commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 06:53:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 17 Feb 2014 06:53:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1643) Client-side transaction handler incorrectly assumes it's needed to be invoked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1643. ------------------------------ > Client-side transaction handler incorrectly assumes it's needed to be invoked > ----------------------------------------------------------------------------- > > Key: ARQ-1643 > URL: https://issues.jboss.org/browse/ARQ-1643 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: transaction_1.0.1.Final > > > When using embedded containers such as Glassfish, client-side transaction handler kicks in and tries to handle transactions putting it into infinite loop of begin/commit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 06:53:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 17 Feb 2014 06:53:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1618. ------------------------------ > Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1618 > URL: https://issues.jboss.org/browse/ARQ-1618 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Environment: Win7,CentOS > Jboss7, Wildfly8 > Reporter: P?tr Andreev > Assignee: Bartosz Majsak > Priority: Minor > Fix For: transaction_1.0.1.Final > > > The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. > As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:21:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 18 Feb 2014 12:21:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1647) Allow Executor to set process exit code In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1647: -------------------------------- Summary: Allow Executor to set process exit code Key: ARQ-1647 URL: https://issues.jboss.org/browse/ARQ-1647 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Spacelift Affects Versions: spacelift_1.0.0.Alpha1 Reporter: Karel Piwko Currently, it is not possible to setup exit code for external process. This makes handling of execution failure quite complicated. Figure out what API should be used to let user define allowed exit values. 0 is to be kept as default value. Additionally, there might be multiple values to be set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:23:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 18 Feb 2014 12:23:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1647) Allow Executor to set process exit code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945664#comment-12945664 ] Karel Piwko commented on ARQ-1647: ---------------------------------- INFO: Latest commit in aerogear/openshift-origin-cartridge-aerogear-push branch master was a2e343d1a287c794375972db912f9757d84dc8c8 (rhc):Application 'footest' not found. (rhc): Exception in thread "main" org.arquillian.spacelift.process.ProcessExecutionException: Invocation of [Ljava.lang.String;@83754a8 failed with 101 at org.arquillian.spacelift.process.impl.ProcessExecutorImpl.execute(ProcessExecutorImpl.java:154) at org.arquillian.spacelift.process.impl.ProcessExecutorImpl.execute(ProcessExecutorImpl.java:216) at com.redhat.jboss.mobile.cli.AppCartridgeCreateCommand.run(AppCartridgeCreateCommand.java:61) at com.redhat.jboss.mobile.cli.PerfTestEnvCli.main(PerfTestEnvCli.java:16) {code} > Allow Executor to set process exit code > --------------------------------------- > > Key: ARQ-1647 > URL: https://issues.jboss.org/browse/ARQ-1647 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha1 > Reporter: Karel Piwko > > Currently, it is not possible to setup exit code for external process. This makes handling of execution failure quite complicated. > Figure out what API should be used to let user define allowed exit values. 0 is to be kept as default value. Additionally, there might be multiple values to be set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 23:33:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 18 Feb 2014 23:33:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1456) Unable to authenticate to Tomcat 7 - illegal characters in header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1456. ------------------------------ > Unable to authenticate to Tomcat 7 - illegal characters in header > ----------------------------------------------------------------- > > Key: ARQ-1456 > URL: https://issues.jboss.org/browse/ARQ-1456 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR5 > Reporter: Martin Gencur > > I'm constantly getting the following exception when starting a managed Tomcat container (Tomcat 7): > {code} > java.lang.IllegalArgumentException: Illegal character(s) in message header value: Basic YWRtaW46YWRtaW4= > at sun.net.www.protocol.http.HttpURLConnection.checkMessageHeader(HttpURLConnection.java:482) > at sun.net.www.protocol.http.HttpURLConnection.isExternalMessageHeaderAllowed(HttpURLConnection.java:434) > at sun.net.www.protocol.http.HttpURLConnection.setRequestProperty(HttpURLConnection.java:2752) > at org.jboss.arquillian.container.tomcat.CommonTomcatManager.execute(CommonTomcatManager.java:214) > at org.jboss.arquillian.container.tomcat.CommonTomcatManager.list(CommonTomcatManager.java:116) > at org.jboss.arquillian.container.tomcat.CommonTomcatManager.isRunning(CommonTomcatManager.java:123) > at org.jboss.arquillian.container.tomcat.managed_7.TomcatManagedContainer.start(TomcatManagedContainer.java:85) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > {code} > The configuration of the container in arquillian.xml looks like this: > {code} > > > > 8089 > 8080 > ${tomcat.home} > admin > admin > > > {code} > and I indeed configured the right credentials in tomcat-users.xml: > {code} > > > > > {code} > It does not matter which username or password I use as long as they're the same in arquillian.xml and tomcat-users.xml > I found a similar problem and possible solution at https://forums.oracle.com/thread/2200463?start=0&tstart=0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 23:33:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 18 Feb 2014 23:33:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1496) Add a Tomcat 8 embedded container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1496: ------------------------------- Fix Version/s: tomcat_1.0.0.CR6 (was: tomcat_1.0.0.Final) > Add a Tomcat 8 embedded container > --------------------------------- > > Key: ARQ-1496 > URL: https://issues.jboss.org/browse/ARQ-1496 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: tomcat_1.0.0.CR6 > > > {{arquillian-tomcat-embedded-7}} is not compatible with Tomcat 8 due to {{org.apache.catalina.startup.HostConfig}} does not declare {{appBase()}} method anymore. It seems {{host.getAppBaseFile()}} should be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 23:47:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 18 Feb 2014 23:47:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1496) Add a Tomcat 8 embedded container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1496. ------------------------------ > Add a Tomcat 8 embedded container > --------------------------------- > > Key: ARQ-1496 > URL: https://issues.jboss.org/browse/ARQ-1496 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: tomcat_1.0.0.CR6 > > > {{arquillian-tomcat-embedded-7}} is not compatible with Tomcat 8 due to {{org.apache.catalina.startup.HostConfig}} does not declare {{appBase()}} method anymore. It seems {{host.getAppBaseFile()}} should be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 00:15:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 00:15:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1608) Invoke extensions related to AnnotationDeploymentScenarioGenerator in order of deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1608: ------------------------------- Fix Version/s: 1.1.3.Final > Invoke extensions related to AnnotationDeploymentScenarioGenerator in order of deployments > ------------------------------------------------------------------------------------------ > > Key: ARQ-1608 > URL: https://issues.jboss.org/browse/ARQ-1608 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.2.Final > Environment: Win7, Java 6 > Reporter: Robert Panzer > Fix For: 1.1.3.Final > > > Currently there is no order in which for example ProtocolArchiveProcessors are called in case a test class provides multiple deployments. > It would be nice if the extension related to the AnnotationDeploymentScenarioGenerator were called in the same order. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 00:17:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 00:17:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1458) Arquilian tests failed with RuntileException Could not inject members In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1458: ------------------------------- Fix Version/s: 1.1.3.Final > Arquilian tests failed with RuntileException Could not inject members > --------------------------------------------------------------------- > > Key: ARQ-1458 > URL: https://issues.jboss.org/browse/ARQ-1458 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.4.Final, 1.1.0.Final, 1.1.1.Final > Environment: Linux, JEE6, Embedded Glassfish 3.1.1, JPA, CDI, Arquilian 1.0.4 & Arquilian 1.1.0 > Reporter: Thomas Lallart > Fix For: 1.1.3.Final > > > When running more integration tests with Arquilian on Embedded Glassfish, some tests failed with message : > java.lang.RuntimeException: Could not inject members > at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135) > at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78) > at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52) > ... > Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:744) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884) > at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:120) > See also https://community.jboss.org/message/830718 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 00:17:49 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 00:17:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1608) Invoke extensions related to AnnotationDeploymentScenarioGenerator in order of deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1608. -------------------------------- Resolution: Done > Invoke extensions related to AnnotationDeploymentScenarioGenerator in order of deployments > ------------------------------------------------------------------------------------------ > > Key: ARQ-1608 > URL: https://issues.jboss.org/browse/ARQ-1608 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.2.Final > Environment: Win7, Java 6 > Reporter: Robert Panzer > Fix For: 1.1.3.Final > > > Currently there is no order in which for example ProtocolArchiveProcessors are called in case a test class provides multiple deployments. > It would be nice if the extension related to the AnnotationDeploymentScenarioGenerator were called in the same order. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 00:17:49 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 00:17:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1458) Arquilian tests failed with RuntileException Could not inject members In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1458. -------------------------------- Resolution: Done > Arquilian tests failed with RuntileException Could not inject members > --------------------------------------------------------------------- > > Key: ARQ-1458 > URL: https://issues.jboss.org/browse/ARQ-1458 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.4.Final, 1.1.0.Final, 1.1.1.Final > Environment: Linux, JEE6, Embedded Glassfish 3.1.1, JPA, CDI, Arquilian 1.0.4 & Arquilian 1.1.0 > Reporter: Thomas Lallart > Fix For: 1.1.3.Final > > > When running more integration tests with Arquilian on Embedded Glassfish, some tests failed with message : > java.lang.RuntimeException: Could not inject members > at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135) > at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78) > at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52) > ... > Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:744) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884) > at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:120) > See also https://community.jboss.org/message/830718 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 00:57:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 00:57:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1648) Upgrade ShrinkWrap (Archive, Resolver, Descriptors) In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1648: ---------------------------------- Summary: Upgrade ShrinkWrap (Archive, Resolver, Descriptors) Key: ARQ-1648 URL: https://issues.jboss.org/browse/ARQ-1648 Project: Arquillian Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Base Implementation Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.1.3.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 01:11:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 01:11:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1648) Upgrade ShrinkWrap (Archive, Resolver, Descriptors) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1648. -------------------------------- Resolution: Done > Upgrade ShrinkWrap (Archive, Resolver, Descriptors) > --------------------------------------------------- > > Key: ARQ-1648 > URL: https://issues.jboss.org/browse/ARQ-1648 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Base Implementation > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.3.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 01:25:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 01:25:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1648) Upgrade ShrinkWrap (Archive, Resolver, Descriptors) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1648. ------------------------------ > Upgrade ShrinkWrap (Archive, Resolver, Descriptors) > --------------------------------------------------- > > Key: ARQ-1648 > URL: https://issues.jboss.org/browse/ARQ-1648 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Base Implementation > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 1.1.3.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 01:25:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 01:25:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1458) Arquilian tests failed with RuntileException Could not inject members In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1458. ------------------------------ > Arquilian tests failed with RuntileException Could not inject members > --------------------------------------------------------------------- > > Key: ARQ-1458 > URL: https://issues.jboss.org/browse/ARQ-1458 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.4.Final, 1.1.0.Final, 1.1.1.Final > Environment: Linux, JEE6, Embedded Glassfish 3.1.1, JPA, CDI, Arquilian 1.0.4 & Arquilian 1.1.0 > Reporter: Thomas Lallart > Fix For: 1.1.3.Final > > > When running more integration tests with Arquilian on Embedded Glassfish, some tests failed with message : > java.lang.RuntimeException: Could not inject members > at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135) > at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78) > at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52) > ... > Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:744) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884) > at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:120) > See also https://community.jboss.org/message/830718 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 01:25:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 01:25:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1608) Invoke extensions related to AnnotationDeploymentScenarioGenerator in order of deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1608. ------------------------------ > Invoke extensions related to AnnotationDeploymentScenarioGenerator in order of deployments > ------------------------------------------------------------------------------------------ > > Key: ARQ-1608 > URL: https://issues.jboss.org/browse/ARQ-1608 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.2.Final > Environment: Win7, Java 6 > Reporter: Robert Panzer > Fix For: 1.1.3.Final > > > Currently there is no order in which for example ProtocolArchiveProcessors are called in case a test class provides multiple deployments. > It would be nice if the extension related to the AnnotationDeploymentScenarioGenerator were called in the same order. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 03:43:47 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 19 Feb 2014 03:43:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1649) FrameworkMBean.installBundle() uses URL to local maven repo In-Reply-To: References: Message-ID: Thomas Diesler created ARQ-1649: ----------------------------------- Summary: FrameworkMBean.installBundle() uses URL to local maven repo Key: ARQ-1649 URL: https://issues.jboss.org/browse/ARQ-1649 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: OSGi Containers Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: osgi_2.0.0.Final Auto install of the arquillian-bundle may fail on remote target containers. The target container is given an URL to the arquillian-bundle that may point to the client's local maven repo -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 04:07:47 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 19 Feb 2014 04:07:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1650) Managed container bypasses tomcat jul setup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated ARQ-1650: -------------------------------- Fix Version/s: tomcat_1.0.0.Final > Managed container bypasses tomcat jul setup > ------------------------------------------- > > Key: ARQ-1650 > URL: https://issues.jboss.org/browse/ARQ-1650 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR5 > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: tomcat_1.0.0.Final > > > This code from the catalina startup script is not done in the manged deployable container > {code} > # Set juli LogManager config file if it is present and an override has not been issued > if [ -z "$LOGGING_CONFIG" ]; then > if [ -r "$CATALINA_BASE"/conf/logging.properties ]; then > LOGGING_CONFIG="-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties" > else > # Bugzilla 45585 > LOGGING_CONFIG="-Dnop" > fi > fi > if [ -z "$LOGGING_MANAGER" ]; then > LOGGING_MANAGER="-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" > fi > {code} > As a result, tomcat logging does not work -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 04:07:47 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 19 Feb 2014 04:07:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1650) Managed container bypasses tomcat jul setup In-Reply-To: References: Message-ID: Thomas Diesler created ARQ-1650: ----------------------------------- Summary: Managed container bypasses tomcat jul setup Key: ARQ-1650 URL: https://issues.jboss.org/browse/ARQ-1650 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR5 Reporter: Thomas Diesler This code from the catalina startup script is not done in the manged deployable container {code} # Set juli LogManager config file if it is present and an override has not been issued if [ -z "$LOGGING_CONFIG" ]; then if [ -r "$CATALINA_BASE"/conf/logging.properties ]; then LOGGING_CONFIG="-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties" else # Bugzilla 45585 LOGGING_CONFIG="-Dnop" fi fi if [ -z "$LOGGING_MANAGER" ]; then LOGGING_MANAGER="-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" fi {code} As a result, tomcat logging does not work -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 04:07:47 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 19 Feb 2014 04:07:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1650) Managed container bypasses tomcat jul setup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler reassigned ARQ-1650: ----------------------------------- Assignee: Thomas Diesler > Managed container bypasses tomcat jul setup > ------------------------------------------- > > Key: ARQ-1650 > URL: https://issues.jboss.org/browse/ARQ-1650 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR5 > Reporter: Thomas Diesler > Assignee: Thomas Diesler > > This code from the catalina startup script is not done in the manged deployable container > {code} > # Set juli LogManager config file if it is present and an override has not been issued > if [ -z "$LOGGING_CONFIG" ]; then > if [ -r "$CATALINA_BASE"/conf/logging.properties ]; then > LOGGING_CONFIG="-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties" > else > # Bugzilla 45585 > LOGGING_CONFIG="-Dnop" > fi > fi > if [ -z "$LOGGING_MANAGER" ]; then > LOGGING_MANAGER="-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" > fi > {code} > As a result, tomcat logging does not work -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 04:09:47 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 19 Feb 2014 04:09:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1650) Managed container bypasses tomcat jul setup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945844#comment-12945844 ] Thomas Diesler commented on ARQ-1650: ------------------------------------- As a workaround you can add this to your arquillian.xml {code} -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=${tomcat.home}/conf/logging.properties {code} > Managed container bypasses tomcat jul setup > ------------------------------------------- > > Key: ARQ-1650 > URL: https://issues.jboss.org/browse/ARQ-1650 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR5 > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: tomcat_1.0.0.Final > > > This code from the catalina startup script is not done in the manged deployable container > {code} > # Set juli LogManager config file if it is present and an override has not been issued > if [ -z "$LOGGING_CONFIG" ]; then > if [ -r "$CATALINA_BASE"/conf/logging.properties ]; then > LOGGING_CONFIG="-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties" > else > # Bugzilla 45585 > LOGGING_CONFIG="-Dnop" > fi > fi > if [ -z "$LOGGING_MANAGER" ]; then > LOGGING_MANAGER="-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" > fi > {code} > As a result, tomcat logging does not work -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 04:13:47 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 19 Feb 2014 04:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1651) No console logging with managed karaf container In-Reply-To: References: Message-ID: Thomas Diesler created ARQ-1651: ----------------------------------- Summary: No console logging with managed karaf container Key: ARQ-1651 URL: https://issues.jboss.org/browse/ARQ-1651 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: OSGi Containers Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: osgi_2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 09:41:49 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 09:41:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1071) NullPointerException when timeout is set in @Test when using JUnit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen reopened ARQ-1071: -------------------------------- > NullPointerException when timeout is set in @Test when using JUnit > ------------------------------------------------------------------ > > Key: ARQ-1071 > URL: https://issues.jboss.org/browse/ARQ-1071 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.Final, 1.0.1.Final > Reporter: Rick-Rainer Ludwig > Fix For: 1.0.4.Final > > > When defining a timeout in @Test of JUnit Arquillian throws a NullPointerException: > {code} > java.lang.NullPointerException > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOfTimeout.java:62) > {code} > The code to reproduce this: > {code} > import org.jboss.arquillian.junit.Arquillian; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class TestTimeout { > @Test(timeout = 3000) > public void test() throws Exception { > Thread.sleep(1000); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 09:41:50 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 09:41:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1071) NullPointerException when timeout is set in @Test when using JUnit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1071: ------------------------------- Fix Version/s: (was: 1.0.4.Final) > NullPointerException when timeout is set in @Test when using JUnit > ------------------------------------------------------------------ > > Key: ARQ-1071 > URL: https://issues.jboss.org/browse/ARQ-1071 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.Final, 1.0.1.Final > Reporter: Rick-Rainer Ludwig > > When defining a timeout in @Test of JUnit Arquillian throws a NullPointerException: > {code} > java.lang.NullPointerException > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOfTimeout.java:62) > {code} > The code to reproduce this: > {code} > import org.jboss.arquillian.junit.Arquillian; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class TestTimeout { > @Test(timeout = 3000) > public void test() throws Exception { > Thread.sleep(1000); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 09:43:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 09:43:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1071) NullPointerException when timeout is set in @Test when using JUnit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945982#comment-12945982 ] Aslak Knutsen commented on ARQ-1071: ------------------------------------ ReOpened since applied fix was causing multiple other problems and has been reverted. > NullPointerException when timeout is set in @Test when using JUnit > ------------------------------------------------------------------ > > Key: ARQ-1071 > URL: https://issues.jboss.org/browse/ARQ-1071 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.Final, 1.0.1.Final > Reporter: Rick-Rainer Ludwig > > When defining a timeout in @Test of JUnit Arquillian throws a NullPointerException: > {code} > java.lang.NullPointerException > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOfTimeout.java:62) > {code} > The code to reproduce this: > {code} > import org.jboss.arquillian.junit.Arquillian; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class TestTimeout { > @Test(timeout = 3000) > public void test() throws Exception { > Thread.sleep(1000); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 09:43:49 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 09:43:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1071) NullPointerException when timeout is set in @Test when using JUnit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945982#comment-12945982 ] Aslak Knutsen edited comment on ARQ-1071 at 2/19/14 9:43 AM: ------------------------------------------------------------- ReOpened since applied fix was causing multiple other problems and has been reverted. (ARQ-1458 ) was (Author: aslak): ReOpened since applied fix was causing multiple other problems and has been reverted. > NullPointerException when timeout is set in @Test when using JUnit > ------------------------------------------------------------------ > > Key: ARQ-1071 > URL: https://issues.jboss.org/browse/ARQ-1071 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.Final, 1.0.1.Final > Reporter: Rick-Rainer Ludwig > > When defining a timeout in @Test of JUnit Arquillian throws a NullPointerException: > {code} > java.lang.NullPointerException > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOfTimeout.java:62) > {code} > The code to reproduce this: > {code} > import org.jboss.arquillian.junit.Arquillian; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class TestTimeout { > @Test(timeout = 3000) > public void test() throws Exception { > Thread.sleep(1000); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 09:43:49 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 09:43:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1071) NullPointerException when timeout is set in @Test when using JUnit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1071: ------------------------------- Affects Version/s: 1.1.3.Final > NullPointerException when timeout is set in @Test when using JUnit > ------------------------------------------------------------------ > > Key: ARQ-1071 > URL: https://issues.jboss.org/browse/ARQ-1071 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.Final, 1.0.1.Final, 1.1.3.Final > Reporter: Rick-Rainer Ludwig > > When defining a timeout in @Test of JUnit Arquillian throws a NullPointerException: > {code} > java.lang.NullPointerException > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOfTimeout.java:62) > {code} > The code to reproduce this: > {code} > import org.jboss.arquillian.junit.Arquillian; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class TestTimeout { > @Test(timeout = 3000) > public void test() throws Exception { > Thread.sleep(1000); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 10:13:48 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 19 Feb 2014 10:13:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1652) Cannot auto install arquillian-bundle on windows In-Reply-To: References: Message-ID: Thomas Diesler created ARQ-1652: ----------------------------------- Summary: Cannot auto install arquillian-bundle on windows Key: ARQ-1652 URL: https://issues.jboss.org/browse/ARQ-1652 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: OSGi Containers Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: osgi_2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 21:13:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 21:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-628) Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-628: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: tomcat_1.0.0.Final Resolution: Done > Tomcat managed throws NullPointerException when application under test brings weld-servlet dependency > ----------------------------------------------------------------------------------------------------- > > Key: ARQ-628 > URL: https://issues.jboss.org/browse/ARQ-628 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR2 > Environment: tomcat-managed-7 > application - richfaces-showcase-4.1.0-20111011-M3-tomcat6.war > Reporter: Juraj H?ska > Fix For: tomcat_1.0.0.Final > > > I have encountered this issue when I was testing richfaces-showcase application. It seems that tomcat-managed-7 has problem with applications which bring own weld-servlet dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 21:13:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 19 Feb 2014 21:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1650) Managed container bypasses tomcat jul setup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1650. -------------------------------- Resolution: Done pushed upstream https://github.com/arquillian/arquillian-container-tomcat/commit/b0bca68dd9e13357f4619d7934276068a65cfdde > Managed container bypasses tomcat jul setup > ------------------------------------------- > > Key: ARQ-1650 > URL: https://issues.jboss.org/browse/ARQ-1650 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR5 > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: tomcat_1.0.0.Final > > > This code from the catalina startup script is not done in the manged deployable container > {code} > # Set juli LogManager config file if it is present and an override has not been issued > if [ -z "$LOGGING_CONFIG" ]; then > if [ -r "$CATALINA_BASE"/conf/logging.properties ]; then > LOGGING_CONFIG="-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties" > else > # Bugzilla 45585 > LOGGING_CONFIG="-Dnop" > fi > fi > if [ -z "$LOGGING_MANAGER" ]; then > LOGGING_MANAGER="-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" > fi > {code} > As a result, tomcat logging does not work -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 20 03:13:47 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 20 Feb 2014 03:13:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-422) Regression in request guard In-Reply-To: References: Message-ID: Pavol Pitonak created ARQGRA-422: ------------------------------------ Summary: Regression in request guard Key: ARQGRA-422 URL: https://issues.jboss.org/browse/ARQGRA-422 Project: Arquillian Graphene Issue Type: Bug Components: core Affects Versions: 2.0.1.Final Environment: RichFaces 5.0.0-SNAPSHOT Arquillian Core 1.1.2.Final Arquillian Drone 1.2.3.Final Arquillian Graphene 2.0.1.Final Selenium 2.39.0 Reporter: Pavol Pitonak I have a simple page with two inputs, a submit button and two notify messages (one for each input) - https://github.com/richfaces/richfaces-qa/blob/requestGuardReproducer/metamer/application/src/main/webapp/components/richNotifyMessage/guardReproducer.xhtml When you guard ajax request when button is clicked, it fails with timeout: {code} org.openqa.selenium.TimeoutException: Timed out after 2 seconds waiting for org.jboss.arquillian.graphene.guard.RequestGuardFactory$RequestIsDone at 19eda624 {code} * when you run test (in Steps to Reproduce) all three tests fail on request guard (guarding Ajax request) * it doesn't matter how WebElement is obtained (WebDriver.find, \@FindBy or \@Page * these tests fail only when two validation errors are on page, i.e. when two notifyMessage components are displayed ** e.g. change value of second input from 888 to 8 in guardReproducer.xhtml and it will work * worked fine with Graphene 2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 20 08:17:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 20 Feb 2014 08:17:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-422) Regression in request guard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-422: --------------------------------- Assignee: Luk?? Fry? > Regression in request guard > --------------------------- > > Key: ARQGRA-422 > URL: https://issues.jboss.org/browse/ARQGRA-422 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.1.Final > Environment: RichFaces 5.0.0-SNAPSHOT > Arquillian Core 1.1.2.Final > Arquillian Drone 1.2.3.Final > Arquillian Graphene 2.0.1.Final > Selenium 2.39.0 > Reporter: Pavol Pitonak > Assignee: Luk?? Fry? > > I have a simple page with two inputs, a submit button and two notify messages (one for each input) - > https://github.com/richfaces/richfaces-qa/blob/requestGuardReproducer/metamer/application/src/main/webapp/components/richNotifyMessage/guardReproducer.xhtml > When you guard ajax request when button is clicked, it fails with timeout: > {code} > org.openqa.selenium.TimeoutException: Timed out after 2 seconds waiting for org.jboss.arquillian.graphene.guard.RequestGuardFactory$RequestIsDone at 19eda624 > {code} > * when you run test (in Steps to Reproduce) all three tests fail on request guard (guarding Ajax request) > * it doesn't matter how WebElement is obtained (WebDriver.find, \@FindBy or \@Page > * these tests fail only when two validation errors are on page, i.e. when two notifyMessage components are displayed > ** e.g. change value of second input from 888 to 8 in guardReproducer.xhtml and it will work > * worked fine with Graphene 2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 20 08:29:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 20 Feb 2014 08:29:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-422) Regression in request guard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12946365#comment-12946365 ] Luk?? Fry? commented on ARQGRA-422: ----------------------------------- I can confirm the test works with 2.0.0.Final. Thanks for nice reproducer, Pavol. > Regression in request guard > --------------------------- > > Key: ARQGRA-422 > URL: https://issues.jboss.org/browse/ARQGRA-422 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.1.Final > Environment: RichFaces 5.0.0-SNAPSHOT > Arquillian Core 1.1.2.Final > Arquillian Drone 1.2.3.Final > Arquillian Graphene 2.0.1.Final > Selenium 2.39.0 > Reporter: Pavol Pitonak > Assignee: Luk?? Fry? > > I have a simple page with two inputs, a submit button and two notify messages (one for each input) - > https://github.com/richfaces/richfaces-qa/blob/requestGuardReproducer/metamer/application/src/main/webapp/components/richNotifyMessage/guardReproducer.xhtml > When you guard ajax request when button is clicked, it fails with timeout: > {code} > org.openqa.selenium.TimeoutException: Timed out after 2 seconds waiting for org.jboss.arquillian.graphene.guard.RequestGuardFactory$RequestIsDone at 19eda624 > {code} > * when you run test (in Steps to Reproduce) all three tests fail on request guard (guarding Ajax request) > * it doesn't matter how WebElement is obtained (WebDriver.find, \@FindBy or \@Page > * these tests fail only when two validation errors are on page, i.e. when two notifyMessage components are displayed > ** e.g. change value of second input from 888 to 8 in guardReproducer.xhtml and it will work > * worked fine with Graphene 2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 20 08:29:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 20 Feb 2014 08:29:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-422) Regression in request guard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQGRA-422 started by Luk?? Fry?. > Regression in request guard > --------------------------- > > Key: ARQGRA-422 > URL: https://issues.jboss.org/browse/ARQGRA-422 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.1.Final > Environment: RichFaces 5.0.0-SNAPSHOT > Arquillian Core 1.1.2.Final > Arquillian Drone 1.2.3.Final > Arquillian Graphene 2.0.1.Final > Selenium 2.39.0 > Reporter: Pavol Pitonak > Assignee: Luk?? Fry? > > I have a simple page with two inputs, a submit button and two notify messages (one for each input) - > https://github.com/richfaces/richfaces-qa/blob/requestGuardReproducer/metamer/application/src/main/webapp/components/richNotifyMessage/guardReproducer.xhtml > When you guard ajax request when button is clicked, it fails with timeout: > {code} > org.openqa.selenium.TimeoutException: Timed out after 2 seconds waiting for org.jboss.arquillian.graphene.guard.RequestGuardFactory$RequestIsDone at 19eda624 > {code} > * when you run test (in Steps to Reproduce) all three tests fail on request guard (guarding Ajax request) > * it doesn't matter how WebElement is obtained (WebDriver.find, \@FindBy or \@Page > * these tests fail only when two validation errors are on page, i.e. when two notifyMessage components are displayed > ** e.g. change value of second input from 888 to 8 in guardReproducer.xhtml and it will work > * worked fine with Graphene 2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 20 08:29:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Thu, 20 Feb 2014 08:29:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-422) Regression in request guard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-422: ------------------------------ Priority: Blocker (was: Major) > Regression in request guard > --------------------------- > > Key: ARQGRA-422 > URL: https://issues.jboss.org/browse/ARQGRA-422 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.1.Final > Environment: RichFaces 5.0.0-SNAPSHOT > Arquillian Core 1.1.2.Final > Arquillian Drone 1.2.3.Final > Arquillian Graphene 2.0.1.Final > Selenium 2.39.0 > Reporter: Pavol Pitonak > Assignee: Luk?? Fry? > Priority: Blocker > > I have a simple page with two inputs, a submit button and two notify messages (one for each input) - > https://github.com/richfaces/richfaces-qa/blob/requestGuardReproducer/metamer/application/src/main/webapp/components/richNotifyMessage/guardReproducer.xhtml > When you guard ajax request when button is clicked, it fails with timeout: > {code} > org.openqa.selenium.TimeoutException: Timed out after 2 seconds waiting for org.jboss.arquillian.graphene.guard.RequestGuardFactory$RequestIsDone at 19eda624 > {code} > * when you run test (in Steps to Reproduce) all three tests fail on request guard (guarding Ajax request) > * it doesn't matter how WebElement is obtained (WebDriver.find, \@FindBy or \@Page > * these tests fail only when two validation errors are on page, i.e. when two notifyMessage components are displayed > ** e.g. change value of second input from 888 to 8 in guardReproducer.xhtml and it will work > * worked fine with Graphene 2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 02:05:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 21 Feb 2014 02:05:47 -0500 (EST) 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=12946688#comment-12946688 ] Bartosz Majsak commented on ARQ-1444: ------------------------------------- Hi Michel, many thanks for your contribution. [I built upon|https://github.com/arquillian/arquillian-extension-persistence/commit/b649764b43a43a17d3eaf697fec69ee8e6d119ca] your PR and extended it to provide some PL/SQL bits (so you can for instance easily have "drop-create" ddls). We will release new version shortly. > 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 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 02:05:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 21 Feb 2014 02:05:48 -0500 (EST) 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:all-tabpanel ] Bartosz Majsak updated ARQ-1444: -------------------------------- Fix Version/s: persistence_1.0.0.next > 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.next > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 02:05:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 21 Feb 2014 02:05:48 -0500 (EST) 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:all-tabpanel ] Bartosz Majsak updated ARQ-1444: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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.next > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 03:51:47 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 21 Feb 2014 03:51:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1634) Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated ARQ-1634: ----------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/34 (was: https://github.com/arquillian/arquillian-extension-drone/pull/33) Linking new pull request with fixed test. > Automatic augmentation of RemoteWebDriver is not done - canEnhance returns always false > --------------------------------------------------------------------------------------- > > Key: ARQ-1634 > URL: https://issues.jboss.org/browse/ARQ-1634 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Environment: Drone 1.2.3.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Fix For: drone_1.2.4.Final > > > {{RemoteWebDriver}} should be augmented automatically, so we can take screenshots from it. > It is not, because {{AugmentingEnhancer#canEnhance}} returns always false. > The cause is on [this|https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/main/java/org/jboss/arquillian/drone/webdriver/augmentation/AugmentingEnhancer.java#L78] line. According to @kpiwko there should be logical _and_. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 07:25:47 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Fri, 21 Feb 2014 07:25:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1651) No console logging with managed karaf container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1651 started by Thomas Diesler. > No console logging with managed karaf container > ----------------------------------------------- > > Key: ARQ-1651 > URL: https://issues.jboss.org/browse/ARQ-1651 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: osgi_2.0.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 08:11:50 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Fri, 21 Feb 2014 08:11:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1651) No console logging with managed karaf container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved ARQ-1651. --------------------------------- Resolution: Done Fixed in 2.1.0.CR12 > No console logging with managed karaf container > ----------------------------------------------- > > Key: ARQ-1651 > URL: https://issues.jboss.org/browse/ARQ-1651 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi Containers > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: osgi_2.0.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 08:11:50 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 21 Feb 2014 08:11:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-423) Provide a way to intercept in some order In-Reply-To: References: Message-ID: Juraj H?ska created ARQGRA-423: ---------------------------------- Summary: 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 Components: core Affects Versions: 2.0.1.Final Reporter: Juraj H?ska 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 08:11:51 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 21 Feb 2014 08:11:51 -0500 (EST) 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 ] Juraj H?ska reassigned ARQGRA-423: ---------------------------------- Assignee: Juraj H?ska > 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 > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 08:17:49 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 21 Feb 2014 08:17:49 -0500 (EST) 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 ] Juraj H?ska updated ARQGRA-423: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/95 > 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 > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Juraj H?ska > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 09:01:48 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Fri, 21 Feb 2014 09:01:48 -0500 (EST) 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:comment-tabpanel&focusedCommentId=12946878#comment-12946878 ] Stefan Miklosovic commented on ARQGRA-420: ------------------------------------------ [~lfryc] any idea where you want to put that extension in graphene source tree? I was thinking about placing it into root, besides api / impl / spi but I am not sure about your preferencies. https://community.jboss.org/message/856219#856219 > 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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 04:09:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 04:09:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1653) Drone use concurrent.ExecutorService without Context inheritance on Threads In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1653: ---------------------------------- Summary: Drone use concurrent.ExecutorService without Context inheritance on Threads Key: ARQ-1653 URL: https://issues.jboss.org/browse/ARQ-1653 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: 1.1.3.Final, drone_1.2.3.Final Reporter: Aslak Knutsen Context's in Arquillian are bound to ThreadLocals within their lifecycle. In Core 1.0.4.Final this was changed to use InheritableThreadLocal to fix an issue with the TestFramework not finding Core when executing multiple threads. This had some unforeseen consequences and in the end reverted in 1.1.3.Final. Somewhere inbetween those versions, Drone started to use a Threaded WebDriver creation to allow timeout control. This is now failing, since the InstanceCallable is called on a 'empty' Thread. https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneInstanceCreator.java#L84 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 04:15:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 04:15:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1653) Drone use concurrent.ExecutorService without Context inheritance on Threads In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947089#comment-12947089 ] Aslak Knutsen commented on ARQ-1653: ------------------------------------ I have a patch in the works that fix it in Drone using a similar technique as used by the ServletProtocol; https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/execution/RemoteTestExecuter.java#L136 Tho, I think a long term fix is to expose a ExecutorService service in Core that can handle this internally, to avoid leaking to much impl details into the extensions. > Drone use concurrent.ExecutorService without Context inheritance on Threads > ---------------------------------------------------------------------------- > > Key: ARQ-1653 > URL: https://issues.jboss.org/browse/ARQ-1653 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final, 1.1.3.Final > Reporter: Aslak Knutsen > > Context's in Arquillian are bound to ThreadLocals within their lifecycle. In Core 1.0.4.Final this was changed to use InheritableThreadLocal to fix an issue with the TestFramework not finding Core when executing multiple threads. This had some unforeseen consequences and in the end reverted in 1.1.3.Final. > Somewhere inbetween those versions, Drone started to use a Threaded WebDriver creation to allow timeout control. This is now failing, since the InstanceCallable is called on a 'empty' Thread. > https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneInstanceCreator.java#L84 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 04:31:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 04:31:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1654: ------------------------------- Fix Version/s: 2.0.0.Beta1 > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit(*) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 04:31:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 04:31:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1654: ------------------------------- Description: Expose a Service to execute Callable's and Runnable's within a Inherited context. The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. The submit\(\*\) methods should probably be enough. was: Expose a Service to execute Callable's and Runnable's within a Inherited context. The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. The submit(*) methods should probably be enough. > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 04:31:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 04:31:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1654: ---------------------------------- Summary: Expose an ExecutorService to help Extension with multithreading Key: ARQ-1654 URL: https://issues.jboss.org/browse/ARQ-1654 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.1.3.Final Reporter: Aslak Knutsen Expose a Service to execute Callable's and Runnable's within a Inherited context. The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. The submit(*) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 04:31:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 04:31:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen reassigned ARQ-1654: ---------------------------------- Assignee: Aslak Knutsen > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 11:51:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 11:51:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1653) Drone use concurrent.ExecutorService without Context inheritance on Threads In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1653: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-drone/pull/35 > Drone use concurrent.ExecutorService without Context inheritance on Threads > ---------------------------------------------------------------------------- > > Key: ARQ-1653 > URL: https://issues.jboss.org/browse/ARQ-1653 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final, 1.1.3.Final > Reporter: Aslak Knutsen > > Context's in Arquillian are bound to ThreadLocals within their lifecycle. In Core 1.0.4.Final this was changed to use InheritableThreadLocal to fix an issue with the TestFramework not finding Core when executing multiple threads. This had some unforeseen consequences and in the end reverted in 1.1.3.Final. > Somewhere inbetween those versions, Drone started to use a Threaded WebDriver creation to allow timeout control. This is now failing, since the InstanceCallable is called on a 'empty' Thread. > https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneInstanceCreator.java#L84 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sun Feb 23 11:53:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Sun, 23 Feb 2014 11:53:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1653) Drone use concurrent.ExecutorService without Context inheritance on Threads In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen reassigned ARQ-1653: ---------------------------------- Assignee: Aslak Knutsen > Drone use concurrent.ExecutorService without Context inheritance on Threads > ---------------------------------------------------------------------------- > > Key: ARQ-1653 > URL: https://issues.jboss.org/browse/ARQ-1653 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final, 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > > Context's in Arquillian are bound to ThreadLocals within their lifecycle. In Core 1.0.4.Final this was changed to use InheritableThreadLocal to fix an issue with the TestFramework not finding Core when executing multiple threads. This had some unforeseen consequences and in the end reverted in 1.1.3.Final. > Somewhere inbetween those versions, Drone started to use a Threaded WebDriver creation to allow timeout control. This is now failing, since the InstanceCallable is called on a 'empty' Thread. > https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneInstanceCreator.java#L84 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 03:33:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 24 Feb 2014 03:33:47 -0500 (EST) 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:comment-tabpanel&focusedCommentId=12947185#comment-12947185 ] Luk?? Fry? commented on ARQGRA-420: ----------------------------------- Does it makes sense to place it into {{impl}} under {{org.jboss.arquillian.graphene.integration}} package? It would need to make sure that extension won't try to register itself unless appropriate API artifacts are on classpath. > 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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 04:21:47 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Mon, 24 Feb 2014 04:21:47 -0500 (EST) 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:comment-tabpanel&focusedCommentId=12947212#comment-12947212 ] Stefan Miklosovic commented on ARQGRA-420: ------------------------------------------ Well, the idea is just to ship it with Graphene in some way or have it in some kind of bom so it would not been technically on classpath unless you explicity use that dependency in your target pom. I would go for placing it to impl/screenshooter and make it as standalone dependency. However I am not sure what about versioning then. > 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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 07:03:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 24 Feb 2014 07:03:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947305#comment-12947305 ] Karel Piwko commented on ARQ-1654: ---------------------------------- This might get incorporated into Spacelift. Spacelift already has an executor service and provides a submit(*) method: https://github.com/arquillian/arquillian-spacelift/blob/master/spacelift-api/src/main/java/org/arquillian/spacelift/process/ProcessExecutor.java Or the other way around, some parts of Spacelift might become the core. > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 07:49:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 24 Feb 2014 07:49:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1653) Drone use concurrent.ExecutorService without Context inheritance on Threads In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947323#comment-12947323 ] Karel Piwko commented on ARQ-1653: ---------------------------------- Pushed upstream for Drone in https://github.com/arquillian/arquillian-extension-drone/commit/38c31b9c26246d1fb37e043e4fbc3c41d724549a > Drone use concurrent.ExecutorService without Context inheritance on Threads > ---------------------------------------------------------------------------- > > Key: ARQ-1653 > URL: https://issues.jboss.org/browse/ARQ-1653 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final, 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > > Context's in Arquillian are bound to ThreadLocals within their lifecycle. In Core 1.0.4.Final this was changed to use InheritableThreadLocal to fix an issue with the TestFramework not finding Core when executing multiple threads. This had some unforeseen consequences and in the end reverted in 1.1.3.Final. > Somewhere inbetween those versions, Drone started to use a Threaded WebDriver creation to allow timeout control. This is now failing, since the InstanceCallable is called on a 'empty' Thread. > https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneInstanceCreator.java#L84 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 07:49:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 24 Feb 2014 07:49:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1653) Drone use concurrent.ExecutorService without Context inheritance on Threads In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1653: ----------------------------- Fix Version/s: drone_1.2.4.Final > Drone use concurrent.ExecutorService without Context inheritance on Threads > ---------------------------------------------------------------------------- > > Key: ARQ-1653 > URL: https://issues.jboss.org/browse/ARQ-1653 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final, 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: drone_1.2.4.Final > > > Context's in Arquillian are bound to ThreadLocals within their lifecycle. In Core 1.0.4.Final this was changed to use InheritableThreadLocal to fix an issue with the TestFramework not finding Core when executing multiple threads. This had some unforeseen consequences and in the end reverted in 1.1.3.Final. > Somewhere inbetween those versions, Drone started to use a Threaded WebDriver creation to allow timeout control. This is now failing, since the InstanceCallable is called on a 'empty' Thread. > https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneInstanceCreator.java#L84 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 07:57:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 24 Feb 2014 07:57:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1638) ChromeDriver binary capability is not propagated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1638: ----------------------------- Summary: ChromeDriver binary capability is not propagated (was: Chrome driver options are not wrapped into ChromeOptions object) > ChromeDriver binary capability is not propagated > ------------------------------------------------ > > Key: ARQ-1638 > URL: https://issues.jboss.org/browse/ARQ-1638 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Karel Piwko > Priority: Critical > Fix For: drone_1.2.4.Final > > > Latest ChromeDriver requires capabilities to be set in ChromeOptions object. > Hence passing stuff like 'binary' from arquillian.properties does not work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 07:57:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 24 Feb 2014 07:57:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1638) ChromeDriver binary capability is not propagated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1638: ----------------------------- Priority: Major (was: Critical) > ChromeDriver binary capability is not propagated > ------------------------------------------------ > > Key: ARQ-1638 > URL: https://issues.jboss.org/browse/ARQ-1638 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Karel Piwko > Fix For: drone_1.2.4.Final > > > Latest ChromeDriver requires capabilities to be set in ChromeOptions object. > Hence passing stuff like 'binary' from arquillian.properties does not work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 07:59:48 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 24 Feb 2014 07:59:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1638) ChromeDriver binary capability is not propagated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1638: ----------------------------- Description: Due to double deprecation checks, something a capability might get lost. For instance: * configuration contains *chromeBinary* field * capability is named *chrome.binary* Hence, when this is set, double deprecation message is emitted but capability is actually never put to map but field is set instead. Factory does not rely on deprecated field, expecting that legacy configurator did the work and value is effectively lost. was: Latest ChromeDriver requires capabilities to be set in ChromeOptions object. Hence passing stuff like 'binary' from arquillian.properties does not work. > ChromeDriver binary capability is not propagated > ------------------------------------------------ > > Key: ARQ-1638 > URL: https://issues.jboss.org/browse/ARQ-1638 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Karel Piwko > Fix For: drone_1.2.4.Final > > > Due to double deprecation checks, something a capability might get lost. > For instance: > * configuration contains *chromeBinary* field > * capability is named *chrome.binary* > Hence, when this is set, double deprecation message is emitted but capability is actually never put to map but field is set instead. Factory does not rely on deprecated field, expecting that legacy configurator did the work and value is effectively lost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 07:59:48 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Mon, 24 Feb 2014 07:59:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1638) ChromeDriver binary capability is not propagated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko resolved ARQ-1638. ------------------------------ Assignee: Karel Piwko Resolution: Done Pushed upstream in https://github.com/arquillian/arquillian-extension-drone/commit/b3e700862026d6218aba4654692cae846273435d > ChromeDriver binary capability is not propagated > ------------------------------------------------ > > Key: ARQ-1638 > URL: https://issues.jboss.org/browse/ARQ-1638 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: drone_1.2.4.Final > > > Due to double deprecation checks, something a capability might get lost. > For instance: > * configuration contains *chromeBinary* field > * capability is named *chrome.binary* > Hence, when this is set, double deprecation message is emitted but capability is actually never put to map but field is set instead. Factory does not rely on deprecated field, expecting that legacy configurator did the work and value is effectively lost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 09:43:47 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Mon, 24 Feb 2014 09:43:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: Juergen Zimmermann created ARQ-1655: --------------------------------------- Summary: NPE in WebDriverFactory.createInstance() Key: ARQ-1655 URL: https://issues.jboss.org/browse/ARQ-1655 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: 1.1.3.Final Reporter: Juergen Zimmermann When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. I also attach the output of "mvn dependency:tree" and arquillian.xml. My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 09:45:50 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Mon, 24 Feb 2014 09:45:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Zimmermann updated ARQ-1655: ------------------------------------ Attachment: stacktrace.txt dependency-tree.txt arquillian.xml > NPE in WebDriverFactory.createInstance() > ---------------------------------------- > > Key: ARQ-1655 > URL: https://issues.jboss.org/browse/ARQ-1655 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: 1.1.3.Final > Reporter: Juergen Zimmermann > Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt > > > When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. > I also attach the output of "mvn dependency:tree" and arquillian.xml. > My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 14:15:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 24 Feb 2014 14:15:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947557#comment-12947557 ] Aslak Knutsen commented on ARQ-1655: ------------------------------------ Would you verify if this is the same bug? https://issues.jboss.org/browse/ARQ-1653 Fix should be upstream. > NPE in WebDriverFactory.createInstance() > ---------------------------------------- > > Key: ARQ-1655 > URL: https://issues.jboss.org/browse/ARQ-1655 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: 1.1.3.Final > Reporter: Juergen Zimmermann > Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt > > > When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. > I also attach the output of "mvn dependency:tree" and arquillian.xml. > My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 14:37:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 24 Feb 2014 14:37:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947563#comment-12947563 ] Aslak Knutsen commented on ARQ-1654: ------------------------------------ The other way around :) But yeah. ProcessExecutor could use the ExecutorService in core. > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 14:39:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 24 Feb 2014 14:39:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947564#comment-12947564 ] Aslak Knutsen commented on ARQ-1654: ------------------------------------ Possible some of the ProcessExecutor could go to container-spi as well. or some managed-container-spi. > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 16:27:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 24 Feb 2014 16:27:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1656) Propogate Contextual operations on HttpFilters In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1656: ---------------------------------- Summary: Propogate Contextual operations on HttpFilters Key: ARQ-1656 URL: https://issues.jboss.org/browse/ARQ-1656 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha6 Environment: Arquillian Core 1.1.3 Reporter: Aslak Knutsen Warp reactivates Context's when creating the client side HttpFilters, but not when executing the actual filtering. In Arquillian Core 1.1.3 the InheritableThreadLocal were removed which now expose this bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 16:27:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 24 Feb 2014 16:27:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1656) Propogate Contextual operations on HttpFilters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen reassigned ARQ-1656: ---------------------------------- Assignee: Aslak Knutsen > Propogate Contextual operations on HttpFilters > ---------------------------------------------- > > Key: ARQ-1656 > URL: https://issues.jboss.org/browse/ARQ-1656 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Environment: Arquillian Core 1.1.3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > > Warp reactivates Context's when creating the client side HttpFilters, but not when executing the actual filtering. > In Arquillian Core 1.1.3 the InheritableThreadLocal were removed which now expose this bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 16:35:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 24 Feb 2014 16:35:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1338) Should be able to define ad-hoc sql script through ApplyScript annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak resolved ARQ-1338. --------------------------------- Resolution: Done Pushed [upstream|https://github.com/arquillian/arquillian-extension-persistence/commit/4e54bdc426de0ac97c52e9598f2170d55b15d16a]. > Should be able to define ad-hoc sql script through ApplyScript annotation > ------------------------------------------------------------------------- > > Key: ARQ-1338 > URL: https://issues.jboss.org/browse/ARQ-1338 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Priority: Minor > Fix For: persistence_1.0.0.next > > > This should be handy for some cases, when external script is not really needed. In particular for some fiddling around with the tests during development / diagnostic of errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 16:37:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 24 Feb 2014 16:37:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1656) Propogate Contextual operations on HttpFilters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1656: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-warp/pull/26 > Propogate Contextual operations on HttpFilters > ---------------------------------------------- > > Key: ARQ-1656 > URL: https://issues.jboss.org/browse/ARQ-1656 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Environment: Arquillian Core 1.1.3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > > Warp reactivates Context's when creating the client side HttpFilters, but not when executing the actual filtering. > In Arquillian Core 1.1.3 the InheritableThreadLocal were removed which now expose this bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 16:39:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 24 Feb 2014 16:39:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1440) Performance drops > 300% In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1440: -------------------------------- Fix Version/s: persistence_1.0.0.next > Performance drops > 300% > ------------------------ > > Key: ARQ-1440 > URL: https://issues.jboss.org/browse/ARQ-1440 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: transaction_1.0.0.Alpha3, persistence_1.0.0.Alpha6 > Environment: Windows 7 / JDK 1.7.0_25 x64 / Oracle 11gR2 / Oracle ojdbc6 driver / Glassfish 3.1.2 b23 / Arquillian 1.1.0-Final / Arq persistence ext 1.0.0a6 / Arq tx ext 1.0.0a3 > Reporter: Noah White > Assignee: Bartosz Majsak > Priority: Critical > Fix For: persistence_1.0.0.next > > > I updated my Arquillian environment to 1.1.0-Final, Arq persistence ext 1.0.0a6 and Arq 1.0.0a3 FROM Arq 1.0.1, persistence 1.0.0a5 (no tx ext in that env since it was part of the persistence ext) and my Arquillian persistence tests which deploy to a managed Glassfish container take over 3x as long as they did in the old environment. > For example one test which took 13s to run in the old environment now takes 44s. > This slow down only seems to affect tests which use the persistence extension. > Arquillian tests which do not use the persistence extension take the same amount of time as they did in the old environment. If I switch the environment back I see the performance goes back up for persistence extension tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 16:41:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 24 Feb 2014 16:41:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1009) ClassNotFoundException when using CLEAN_INSERT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1009: -------------------------------- Fix Version/s: persistence_1.0.0.next > ClassNotFoundException when using CLEAN_INSERT > ---------------------------------------------- > > Key: ARQ-1009 > URL: https://issues.jboss.org/browse/ARQ-1009 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha4 > Environment: Windows 7, Java 1.6.0_31 > Reporter: Karsten Ohme > Fix For: persistence_1.0.0.next > > > I set in arquillian.xml the configuration property: > CLEAN_INSERT > When starting the test I get a ClassNotFoundException in ConfigurationTypeConverter in line 182: > Object instance = Class.forName(value).newInstance(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 16:43:48 2014 From: issues at jboss.org (Karsten Ohme (JIRA)) Date: Mon, 24 Feb 2014 16:43:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1009) ClassNotFoundException when using CLEAN_INSERT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947674#comment-12947674 ] Karsten Ohme commented on ARQ-1009: ----------------------------------- Dear Ladies and Gentlemen, Thank you for your message. I am out of the office until the 3rd of March 2014. Please note: Your e-mail will not be forwarded automatically. Kind regards, Karsten Ohme Sehr geehrte Damen und Herren, vielen Dank f?r Ihre Mitteilung. Ich bin bis Montag, den 03.03.2014 nicht im B?ro. Bitte beachten Sie, dass Ihre E-Mail nicht automatisch weitergeleitet wird. Freundliche Gr??e Karsten Ohme -- Karsten Ohme T-Systems Multimedia Solutions GmbH Portal Technologies, Applications &amp; Appliances Karsten Ohme Softwarearchitekt Hausanschrift: Riesaer Strasse 5, 01129 Dresden Postanschrift: Postfach 10 02 24, 01072 Dresden Telefon: +49 351 28 20 - 2123 Mobil: +49 160 90 54 76 80 Fax: +49 351 28 20 ? 5123 E-Mail: karsten.ohme at t-systems.com Internet: http://www.t-systems-mms.com T-Systems Multimedia Solutions GmbH Aufsichtsrat: Thilo Kusch (Vorsitzender) Gesch?ftsf?hrung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft: Dresden Ust-IdNr.: DE 811 807 949 Hinweis: Der Inhalt dieser E-Mail ist vertraulich und ausschlie?lich f?r den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail sein sollten, setzen Sie sich bitte mit dem Absender der E-Mail oder unter der angegebenen Telefonnummer in Verbindung und vernichten Sie diese E-Mail auf Ihren Speichermedien. Notice: The information contained in this e-mail is confidential. It is intended solely for the addressee named above. If you are not the intended recipient, please notify the sender immediately and destroy this message on any media of yours. > ClassNotFoundException when using CLEAN_INSERT > ---------------------------------------------- > > Key: ARQ-1009 > URL: https://issues.jboss.org/browse/ARQ-1009 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha4 > Environment: Windows 7, Java 1.6.0_31 > Reporter: Karsten Ohme > Fix For: persistence_1.0.0.next > > > I set in arquillian.xml the configuration property: > CLEAN_INSERT > When starting the test I get a ClassNotFoundException in ConfigurationTypeConverter in line 182: > Object instance = Class.forName(value).newInstance(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 17:37:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 24 Feb 2014 17:37:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1398) DatabaseSequenceFilter should be optional In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1398: -------------------------------- Fix Version/s: persistence_1.0.0.next > DatabaseSequenceFilter should be optional > ----------------------------------------- > > Key: ARQ-1398 > URL: https://issues.jboss.org/browse/ARQ-1398 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > Disabled by default, possible to enable through dbunit configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 04:01:48 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 25 Feb 2014 04:01:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1657) Inconsistency in usage of @OperateOnDeployment and OperatesOnDeployment In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1657: -------------------------------- Summary: Inconsistency in usage of @OperateOnDeployment and OperatesOnDeployment Key: ARQ-1657 URL: https://issues.jboss.org/browse/ARQ-1657 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.1.3.Final Reporter: Karel Piwko Priority: Minor In the past, @OperatesOnDeployment was renamed to @OperateOnDeployment. However, not all occurences of @OperatesOnDeployment were removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 04:05:47 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 25 Feb 2014 04:05:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1657) Inconsistency in usage of @OperateOnDeployment and OperatesOnDeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1657: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/64 > Inconsistency in usage of @OperateOnDeployment and OperatesOnDeployment > ----------------------------------------------------------------------- > > Key: ARQ-1657 > URL: https://issues.jboss.org/browse/ARQ-1657 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Karel Piwko > Priority: Minor > > In the past, @OperatesOnDeployment was renamed to @OperateOnDeployment. However, not all occurences of @OperatesOnDeployment were removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 04:05:48 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 25 Feb 2014 04:05:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1657) Inconsistency in usage of @OperateOnDeployment and OperatesOnDeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko reassigned ARQ-1657: -------------------------------- Assignee: Karel Piwko > Inconsistency in usage of @OperateOnDeployment and OperatesOnDeployment > ----------------------------------------------------------------------- > > Key: ARQ-1657 > URL: https://issues.jboss.org/browse/ARQ-1657 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Karel Piwko > Assignee: Karel Piwko > Priority: Minor > > In the past, @OperatesOnDeployment was renamed to @OperateOnDeployment. However, not all occurences of @OperatesOnDeployment were removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 05:15:49 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Tue, 25 Feb 2014 05:15:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1440) Performance drops > 300% In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947800#comment-12947800 ] Bartosz Majsak commented on ARQ-1440: ------------------------------------- Hi [~nwhite]. Would it be possible for you to share the project (or some bits of it)? I have Oracle 11g vm for running the tests now, so I can reproduce and try to nail down your problem. I'm currently investigating all the possible changes which might have lead to this regression. > Performance drops > 300% > ------------------------ > > Key: ARQ-1440 > URL: https://issues.jboss.org/browse/ARQ-1440 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: transaction_1.0.0.Alpha3, persistence_1.0.0.Alpha6 > Environment: Windows 7 / JDK 1.7.0_25 x64 / Oracle 11gR2 / Oracle ojdbc6 driver / Glassfish 3.1.2 b23 / Arquillian 1.1.0-Final / Arq persistence ext 1.0.0a6 / Arq tx ext 1.0.0a3 > Reporter: Noah White > Assignee: Bartosz Majsak > Priority: Critical > Fix For: persistence_1.0.0.next > > > I updated my Arquillian environment to 1.1.0-Final, Arq persistence ext 1.0.0a6 and Arq 1.0.0a3 FROM Arq 1.0.1, persistence 1.0.0a5 (no tx ext in that env since it was part of the persistence ext) and my Arquillian persistence tests which deploy to a managed Glassfish container take over 3x as long as they did in the old environment. > For example one test which took 13s to run in the old environment now takes 44s. > This slow down only seems to affect tests which use the persistence extension. > Arquillian tests which do not use the persistence extension take the same amount of time as they did in the old environment. If I switch the environment back I see the performance goes back up for persistence extension tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 06:09:48 2014 From: issues at jboss.org (Thorben Janssen (JIRA)) Date: Tue, 25 Feb 2014 06:09:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1658) Wrong isInstance check prevents usage of new/custom container In-Reply-To: References: Message-ID: Thorben Janssen created ARQ-1658: ------------------------------------ Summary: Wrong isInstance check prevents usage of new/custom container Key: ARQ-1658 URL: https://issues.jboss.org/browse/ARQ-1658 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Droidium Affects Versions: droidium_1.0.0.Alpha4 Reporter: Thorben Janssen If the container configuration contains an unknown qualifier, MultipleContainerRegistryCreator tries to the adapterImplClass class and checks if it implements DeploableContainer. The current check with isInstance() returns always. The isAssignableFrom() method has to be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 06:29:48 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 25 Feb 2014 06:29:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1658) Wrong isInstance check prevents usage of new/custom container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated ARQ-1658: ----------------------------------- Fix Version/s: droidium_1.0.0.Beta1 > Wrong isInstance check prevents usage of new/custom container > -------------------------------------------------------------- > > Key: ARQ-1658 > URL: https://issues.jboss.org/browse/ARQ-1658 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha4 > Reporter: Thorben Janssen > Fix For: droidium_1.0.0.Beta1 > > > If the container configuration contains an unknown qualifier, MultipleContainerRegistryCreator tries to the adapterImplClass class and checks if it implements DeploableContainer. > The current check with isInstance() returns always. The isAssignableFrom() method has to be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 06:29:48 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 25 Feb 2014 06:29:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1658) Wrong isInstance check prevents usage of new/custom container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947827#comment-12947827 ] Stefan Miklosovic commented on ARQ-1658: ---------------------------------------- pushed upstream https://github.com/arquillian/arquillian-droidium/commit/5a51e6187beb9b3995347b054d51d58a95fa5272 > Wrong isInstance check prevents usage of new/custom container > -------------------------------------------------------------- > > Key: ARQ-1658 > URL: https://issues.jboss.org/browse/ARQ-1658 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha4 > Reporter: Thorben Janssen > Fix For: droidium_1.0.0.Beta1 > > > If the container configuration contains an unknown qualifier, MultipleContainerRegistryCreator tries to the adapterImplClass class and checks if it implements DeploableContainer. > The current check with isInstance() returns always. The isAssignableFrom() method has to be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 06:29:48 2014 From: issues at jboss.org (Stefan Miklosovic (JIRA)) Date: Tue, 25 Feb 2014 06:29:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1658) Wrong isInstance check prevents usage of new/custom container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic resolved ARQ-1658. ------------------------------------ Resolution: Done > Wrong isInstance check prevents usage of new/custom container > -------------------------------------------------------------- > > Key: ARQ-1658 > URL: https://issues.jboss.org/browse/ARQ-1658 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Droidium > Affects Versions: droidium_1.0.0.Alpha4 > Reporter: Thorben Janssen > Fix For: droidium_1.0.0.Beta1 > > > If the container configuration contains an unknown qualifier, MultipleContainerRegistryCreator tries to the adapterImplClass class and checks if it implements DeploableContainer. > The current check with isInstance() returns always. The isAssignableFrom() method has to be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 08:07:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Tue, 25 Feb 2014 08:07:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1440) Performance drops > 300% In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947854#comment-12947854 ] Bartosz Majsak commented on ARQ-1440: ------------------------------------- I ran int-tests module against Oracle11g profile, and here are the results: * 1.0.0.Alpha6 (few tests failing with SQL scripts as I introduced proper handling recently) : 8:35s * Current master: 4:09s There are few changes I did on master: * moved back to the [single database connection for the test method|https://issues.jboss.org/browse/ARQ-1131] * disabled forking for surefire (that was actually huge penalty for my tests, but this have been introduced after releasing 1.0.0.Alpha6) * [made filtering by primary keys optional and disabled by default|https://github.com/arquillian/arquillian-extension-persistence/commit/54cf07dfee4d5bf678128d2382d5a27a74e3bc85] Would it be possible for you to build latest snapshot from master and run your tests against it if that is quicker than sharing your test cases? > Performance drops > 300% > ------------------------ > > Key: ARQ-1440 > URL: https://issues.jboss.org/browse/ARQ-1440 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: transaction_1.0.0.Alpha3, persistence_1.0.0.Alpha6 > Environment: Windows 7 / JDK 1.7.0_25 x64 / Oracle 11gR2 / Oracle ojdbc6 driver / Glassfish 3.1.2 b23 / Arquillian 1.1.0-Final / Arq persistence ext 1.0.0a6 / Arq tx ext 1.0.0a3 > Reporter: Noah White > Assignee: Bartosz Majsak > Priority: Critical > Fix For: persistence_1.0.0.next > > > I updated my Arquillian environment to 1.1.0-Final, Arq persistence ext 1.0.0a6 and Arq 1.0.0a3 FROM Arq 1.0.1, persistence 1.0.0a5 (no tx ext in that env since it was part of the persistence ext) and my Arquillian persistence tests which deploy to a managed Glassfish container take over 3x as long as they did in the old environment. > For example one test which took 13s to run in the old environment now takes 44s. > This slow down only seems to affect tests which use the persistence extension. > Arquillian tests which do not use the persistence extension take the same amount of time as they did in the old environment. If I switch the environment back I see the performance goes back up for persistence extension tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 08:45:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 25 Feb 2014 08:45:48 -0500 (EST) 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:comment-tabpanel&focusedCommentId=12947872#comment-12947872 ] Luk?? Fry? commented on ARQGRA-420: ----------------------------------- If the approach for registering is simply by classpath presense, then it doesn't make sense to include the screenshooter related classes in {{impl/}}. I would prefer to put it into {{extension/screenshooter}} then. > 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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 08:45:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Tue, 25 Feb 2014 08:45:48 -0500 (EST) 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:comment-tabpanel&focusedCommentId=12947873#comment-12947873 ] Luk?? Fry? commented on ARQGRA-420: ----------------------------------- We definitely need to open new branch for 2.1 development. > 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 > Components: api, build, core > Affects Versions: 2.0.1.Final > Reporter: Juraj H?ska > Assignee: Stefan Miklosovic > Fix For: 2.1-Tracking > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 09:37:49 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 25 Feb 2014 09:37:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karel Piwko updated ARQ-1655: ----------------------------- Affects Version/s: drone_1.2.3.Final (was: 1.1.3.Final) > NPE in WebDriverFactory.createInstance() > ---------------------------------------- > > Key: ARQ-1655 > URL: https://issues.jboss.org/browse/ARQ-1655 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Juergen Zimmermann > Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt > > > When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. > I also attach the output of "mvn dependency:tree" and arquillian.xml. > My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 09:43:48 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 25 Feb 2014 09:43:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947893#comment-12947893 ] Karel Piwko commented on ARQ-1655: ---------------------------------- It looks like DroneRegistry is empty. Could you please post output of test running with *-Darquillian.debug* ? I'm wondering why null was injected there. > NPE in WebDriverFactory.createInstance() > ---------------------------------------- > > Key: ARQ-1655 > URL: https://issues.jboss.org/browse/ARQ-1655 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Juergen Zimmermann > Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt > > > When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. > I also attach the output of "mvn dependency:tree" and arquillian.xml. > My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 09:45:50 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 25 Feb 2014 09:45:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947893#comment-12947893 ] Karel Piwko edited comment on ARQ-1655 at 2/25/14 9:45 AM: ----------------------------------------------------------- It indeed looks like DroneRegistry is empty due to ARQ-1653. was (Author: kpiwko): It looks like DroneRegistry is empty. Could you please post output of test running with *-Darquillian.debug* ? I'm wondering why null was injected there. > NPE in WebDriverFactory.createInstance() > ---------------------------------------- > > Key: ARQ-1655 > URL: https://issues.jboss.org/browse/ARQ-1655 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Juergen Zimmermann > Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt > > > When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. > I also attach the output of "mvn dependency:tree" and arquillian.xml. > My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 09:47:48 2014 From: issues at jboss.org (Karel Piwko (JIRA)) Date: Tue, 25 Feb 2014 09:47:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1659) Update Selenium to 2.40.0 In-Reply-To: References: Message-ID: Karel Piwko created ARQ-1659: -------------------------------- Summary: Update Selenium to 2.40.0 Key: ARQ-1659 URL: https://issues.jboss.org/browse/ARQ-1659 Project: Arquillian Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Extension - Drone Affects Versions: drone_1.2.3.Final Reporter: Karel Piwko Update Selenium to support latest browsers. Note, some of the deprecated items might get dropped (AndroidDriver, iOSDriver). We need a strategy how to handle that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 09:51:48 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Tue, 25 Feb 2014 09:51:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947900#comment-12947900 ] Aslak Knutsen commented on ARQ-1655: ------------------------------------ Not so much that the registry is empty, but that there is no Registry. Since there are no Contexts active on the thread it executes. :) > NPE in WebDriverFactory.createInstance() > ---------------------------------------- > > Key: ARQ-1655 > URL: https://issues.jboss.org/browse/ARQ-1655 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Juergen Zimmermann > Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt > > > When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. > I also attach the output of "mvn dependency:tree" and arquillian.xml. > My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 08:12:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 08:12:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1660) Upgrade to TomEE 1.6 In-Reply-To: References: Message-ID: Luk?? Fry? created ARQ-1660: ------------------------------- Summary: Upgrade to TomEE 1.6 Key: ARQ-1660 URL: https://issues.jboss.org/browse/ARQ-1660 Project: Arquillian Issue Type: Feature Request 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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 08:12:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 08:12:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1660) Upgrade to TomEE 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1660: ---------------------------- Issue Type: Component Upgrade (was: Feature Request) > Upgrade to TomEE 1.6 > -------------------- > > Key: ARQ-1660 > URL: https://issues.jboss.org/browse/ARQ-1660 > Project: Arquillian > Issue Type: Component Upgrade > 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 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 08:16:50 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 08:16:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1660) Upgrade to TomEE 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1660. ----------------------------- Assignee: Luk?? Fry? Resolution: Done > Upgrade to TomEE 1.6 > -------------------- > > Key: ARQ-1660 > URL: https://issues.jboss.org/browse/ARQ-1660 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:02:49 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 09:02:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1661) Upgrade GlassFish to 4.0 In-Reply-To: References: Message-ID: Luk?? Fry? created ARQ-1661: ------------------------------- Summary: Upgrade GlassFish to 4.0 Key: ARQ-1661 URL: https://issues.jboss.org/browse/ARQ-1661 Project: Arquillian Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha6 Reporter: Luk?? Fry? Assignee: Luk?? Fry? Fix For: warp_1.0.0.Beta1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:02:50 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 09:02:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1661) Upgrade GlassFish to 4.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948365#comment-12948365 ] Luk?? Fry? commented on ARQ-1661: --------------------------------- The tests fully pass now! woot! But the container fails to stop at the end of surefire-plugin execution: similar to https://issues.jboss.org/browse/ARQ-837 but that issue is fixed > Upgrade GlassFish to 4.0 > ------------------------ > > Key: ARQ-1661 > URL: https://issues.jboss.org/browse/ARQ-1661 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:04:49 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 09:04:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1662) Warp: Upgrade to WildFly 8.0.0.Final In-Reply-To: References: Message-ID: Luk?? Fry? created ARQ-1662: ------------------------------- Summary: Warp: Upgrade to WildFly 8.0.0.Final Key: ARQ-1662 URL: https://issues.jboss.org/browse/ARQ-1662 Project: Arquillian Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Extension - Warp Affects Versions: warp_1.0.0.Alpha6 Reporter: Luk?? Fry? Assignee: Luk?? Fry? Fix For: warp_1.0.0.Beta1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:04:49 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 09:04:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1661) Warp: Upgrade GlassFish to 4.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1661: ---------------------------- Summary: Warp: Upgrade GlassFish to 4.0 (was: Upgrade GlassFish to 4.0) > Warp: Upgrade GlassFish to 4.0 > ------------------------------ > > Key: ARQ-1661 > URL: https://issues.jboss.org/browse/ARQ-1661 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:04:49 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 09:04:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1660) Warp: Upgrade to TomEE 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQ-1660: ---------------------------- Summary: Warp: Upgrade to TomEE 1.6 (was: Upgrade to TomEE 1.6) > Warp: Upgrade to TomEE 1.6 > -------------------------- > > Key: ARQ-1660 > URL: https://issues.jboss.org/browse/ARQ-1660 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:10:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 09:10:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1662) Warp: Upgrade to WildFly 8.0.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1662. ----------------------------- Assignee: Aslak Knutsen (was: Luk?? Fry?) Resolution: Done > Warp: Upgrade to WildFly 8.0.0.Final > ------------------------------------ > > Key: ARQ-1662 > URL: https://issues.jboss.org/browse/ARQ-1662 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Assignee: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:10:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 09:10:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1661) Warp: Upgrade GlassFish to 4.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? resolved ARQ-1661. ----------------------------- Resolution: Done > Warp: Upgrade GlassFish to 4.0 > ------------------------------ > > Key: ARQ-1661 > URL: https://issues.jboss.org/browse/ARQ-1661 > Project: Arquillian > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha6 > Reporter: Luk?? Fry? > Assignee: Luk?? Fry? > Fix For: warp_1.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 10:52:50 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 10:52:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1663) Glassfish fails to shutdown fast enough and breaks subsequent test In-Reply-To: References: Message-ID: Luk?? Fry? created ARQ-1663: ------------------------------- Summary: Glassfish fails to shutdown fast enough and breaks subsequent test Key: ARQ-1663 URL: https://issues.jboss.org/browse/ARQ-1663 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: GlassFish Containers Affects Versions: glassfish_1.0.0.CR4 Reporter: Luk?? Fry? When a maven build is executed with Glassfish 4.0 and Glassfish container adapter 1.0.0.CR4 and the maven contains several modules that run subsequently and make use of Arquillian, the first module doesn't shutdown the test fast enough and this makes the subsequent maven module test execution fail. ---- Reproducer: https://github.com/arquillian/arquillian-extension-warp/commit/3580210318a4559aa1224c06c6637e5ed8e40e49 mvn clean install -Dmaven.test.failure.ignore=true -Dintegration=glassfish40 All the tests in {{jsf-ftest}} module due to the exception that the container wasn't started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 10:54:52 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 10:54:52 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1663) Glassfish fails to shutdown fast enough and breaks subsequent test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948425#comment-12948425 ] Luk?? Fry? commented on ARQ-1663: --------------------------------- As discussed on IRC, we should add port-check after shutdown to ensure GF is down before proceeding with execution. > Glassfish fails to shutdown fast enough and breaks subsequent test > ------------------------------------------------------------------ > > Key: ARQ-1663 > URL: https://issues.jboss.org/browse/ARQ-1663 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: GlassFish Containers > Affects Versions: glassfish_1.0.0.CR4 > Reporter: Luk?? Fry? > > When a maven build is executed with Glassfish 4.0 and Glassfish container adapter 1.0.0.CR4 > and the maven contains several modules that run subsequently and make use of Arquillian, > the first module doesn't shutdown the test fast enough and this makes the subsequent maven module test execution fail. > ---- > Reproducer: > https://github.com/arquillian/arquillian-extension-warp/commit/3580210318a4559aa1224c06c6637e5ed8e40e49 > mvn clean install -Dmaven.test.failure.ignore=true -Dintegration=glassfish40 > All the tests in {{jsf-ftest}} module due to the exception that the container wasn't started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 11:52:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 26 Feb 2014 11:52:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1071) NullPointerException when timeout is set in @Test when using JUnit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1071. -------------------------------- Assignee: Aslak Knutsen Fix Version/s: 1.1.4.Final Resolution: Done upstream https://github.com/arquillian/arquillian-core/commit/c5c73f0fb89114fb9144625053fab139a6f4350c > NullPointerException when timeout is set in @Test when using JUnit > ------------------------------------------------------------------ > > Key: ARQ-1071 > URL: https://issues.jboss.org/browse/ARQ-1071 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.Final, 1.0.1.Final, 1.1.3.Final > Reporter: Rick-Rainer Ludwig > Assignee: Aslak Knutsen > Fix For: 1.1.4.Final > > > When defining a timeout in @Test of JUnit Arquillian throws a NullPointerException: > {code} > java.lang.NullPointerException > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOfTimeout.java:62) > {code} > The code to reproduce this: > {code} > import org.jboss.arquillian.junit.Arquillian; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class TestTimeout { > @Test(timeout = 3000) > public void test() throws Exception { > Thread.sleep(1000); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 13:58:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 26 Feb 2014 13:58:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1663) Glassfish fails to shutdown fast enough and breaks subsequent test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948476#comment-12948476 ] Aslak Knutsen commented on ARQ-1663: ------------------------------------ something similar to this; https://github.com/wildfly/wildfly/blob/master/arquillian/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L218 > Glassfish fails to shutdown fast enough and breaks subsequent test > ------------------------------------------------------------------ > > Key: ARQ-1663 > URL: https://issues.jboss.org/browse/ARQ-1663 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: GlassFish Containers > Affects Versions: glassfish_1.0.0.CR4 > Reporter: Luk?? Fry? > > When a maven build is executed with Glassfish 4.0 and Glassfish container adapter 1.0.0.CR4 > and the maven contains several modules that run subsequently and make use of Arquillian, > the first module doesn't shutdown the test fast enough and this makes the subsequent maven module test execution fail. > ---- > Reproducer: > https://github.com/arquillian/arquillian-extension-warp/commit/3580210318a4559aa1224c06c6637e5ed8e40e49 > mvn clean install -Dmaven.test.failure.ignore=true -Dintegration=glassfish40 > All the tests in {{jsf-ftest}} module due to the exception that the container wasn't started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 14:54:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 26 Feb 2014 14:54:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1131) Improve DBUnit database connection handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948489#comment-12948489 ] Bartosz Majsak commented on ARQ-1131: ------------------------------------- Rolled back to the original approach [@ea0984f|https://github.com/arquillian/arquillian-extension-persistence/commit/ea0984f7cb727865c40675df1989b9bbc940e16a] > Improve DBUnit database connection handling > ------------------------------------------- > > Key: ARQ-1131 > URL: https://issues.jboss.org/browse/ARQ-1131 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > -As Vineet Reynolds pointed out, current implementation initializes the connection and holds on to it, until the verification is performed. It would be better to relinquish the connection after the seeding phase (so utilize it only around "before persistence test" event), and obtain another connection for the dataset verification phase (around "after persistence test" event).- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 14:54:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 26 Feb 2014 14:54:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1131) Improve DBUnit database connection handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1131: -------------------------------- Fix Version/s: (was: persistence_1.0.0.next) > Improve DBUnit database connection handling > ------------------------------------------- > > Key: ARQ-1131 > URL: https://issues.jboss.org/browse/ARQ-1131 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > > -As Vineet Reynolds pointed out, current implementation initializes the connection and holds on to it, until the verification is performed. It would be better to relinquish the connection after the seeding phase (so utilize it only around "before persistence test" event), and obtain another connection for the dataset verification phase (around "after persistence test" event).- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 15:00:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 26 Feb 2014 15:00:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1147) Improve the column filtering feature to use custom IColumnFilter implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1147: -------------------------------- Fix Version/s: persistence_1.0.0.next > Improve the column filtering feature to use custom IColumnFilter implementations > -------------------------------------------------------------------------------- > > Key: ARQ-1147 > URL: https://issues.jboss.org/browse/ARQ-1147 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: persistence_1.0.0.next > > > For now, APE implements column filtering based on column names specified in the {{excludeColumns}} attribute of the {{@ShouldMatchDataSet}} annotation (introduced in ARQ-772). This could be extended to allow custom {{IColumnFilter}} implementations to be plugged in during the verification phase. > The use of {{IColumnFilter}} implementations is described here: http://www.dbunit.org/faq.html#columnfilter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 15:42:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 26 Feb 2014 15:42:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1664) Provide custom table filter for seeding and cleaning databases In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-1664: ----------------------------------- Summary: Provide custom table filter for seeding and cleaning databases Key: ARQ-1664 URL: https://issues.jboss.org/browse/ARQ-1664 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha6 Reporter: Bartosz Majsak Assignee: Bartosz Majsak Fix For: persistence_1.0.0.next In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As itis causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 15:44:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 26 Feb 2014 15:44:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1664) Provide custom table filter for seeding and cleaning databases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1664 started by Bartosz Majsak. > Provide custom table filter for seeding and cleaning databases > -------------------------------------------------------------- > > Key: ARQ-1664 > URL: https://issues.jboss.org/browse/ARQ-1664 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As itis causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 16:10:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 16:10:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948507#comment-12948507 ] Luk?? Fry? commented on ARQ-1654: --------------------------------- In Warp, I have implemented the idea of OperationalContexts: * you can choose what contexts you want to propagate (e.g. what is a lifespan of the callable) * it reflects the hierarchy (nesting) of contexts * allows extensions for custom contexts > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 16:10:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 16:10:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948507#comment-12948507 ] Luk?? Fry? edited comment on ARQ-1654 at 2/26/14 4:09 PM: ---------------------------------------------------------- In Warp, I have implemented the idea of [OperationalContexts|https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/impl/client/context/operation/OperationalContexts.java]: * you can choose what contexts you want to propagate (e.g. what is a lifespan of the callable) * it reflects the hierarchy (nesting) of contexts * allows extensions for custom contexts was (Author: lfryc): In Warp, I have implemented the idea of OperationalContexts: * you can choose what contexts you want to propagate (e.g. what is a lifespan of the callable) * it reflects the hierarchy (nesting) of contexts * allows extensions for custom contexts > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 16:12:47 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 26 Feb 2014 16:12:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948507#comment-12948507 ] Luk?? Fry? edited comment on ARQ-1654 at 2/26/14 4:11 PM: ---------------------------------------------------------- In Warp, I have implemented the idea of [OperationalContexts|https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/impl/client/context/operation/OperationalContexts.java]: * you can choose what contexts you want to propagate (e.g. what is a lifespan of the callable) * it reflects the hierarchy (nesting) of contexts * allows extensions for custom contexts Additional there is [Contextualizer|https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/impl/client/context/operation/Contextualizer.java#L62] that you provide with either OperationalContext or its Retriever and it will make the given instance invocations to activate appropriate contexts. was (Author: lfryc): In Warp, I have implemented the idea of [OperationalContexts|https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/impl/client/context/operation/OperationalContexts.java]: * you can choose what contexts you want to propagate (e.g. what is a lifespan of the callable) * it reflects the hierarchy (nesting) of contexts * allows extensions for custom contexts > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 17:24:47 2014 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 26 Feb 2014 17:24:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948523#comment-12948523 ] Aslak Knutsen commented on ARQ-1654: ------------------------------------ Currently I'm replicating the Context status from the Caller. So env should be == to where it was submitted from. > Expose an ExecutorService to help Extension with multithreading > --------------------------------------------------------------- > > Key: ARQ-1654 > URL: https://issues.jboss.org/browse/ARQ-1654 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.1.3.Final > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: 2.0.0.Beta1 > > > Expose a Service to execute Callable's and Runnable's within a Inherited context. > The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread. > ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely. > The submit\(\*\) methods should probably be enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 27 07:14:47 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Thu, 27 Feb 2014 07:14:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948626#comment-12948626 ] Juergen Zimmermann commented on ARQ-1655: ----------------------------------------- I just tried arquillian-drone-bom Version 1.3.0.Alpha1-SNAPSHOT: the issue is gone. > NPE in WebDriverFactory.createInstance() > ---------------------------------------- > > Key: ARQ-1655 > URL: https://issues.jboss.org/browse/ARQ-1655 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Drone > Affects Versions: drone_1.2.3.Final > Reporter: Juergen Zimmermann > Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt > > > When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace. > I also attach the output of "mvn dependency:tree" and arquillian.xml. > My appserver is WildFly 8.0.0.Final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 27 11:29:49 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Thu, 27 Feb 2014 11:29:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1664) Provide custom table filter for seeding and cleaning databases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak resolved ARQ-1664. --------------------------------- Resolution: Done [Pushed upstream|https://github.com/arquillian/arquillian-extension-persistence/commit/74669cfbf4c0b9df6b76f8e465b2d62fa040d20c] > Provide custom table filter for seeding and cleaning databases > -------------------------------------------------------------- > > Key: ARQ-1664 > URL: https://issues.jboss.org/browse/ARQ-1664 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As itis causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 27 11:31:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Thu, 27 Feb 2014 11:31:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1664) Provide custom table filter for seeding and cleaning databases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1664: -------------------------------- Description: In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As it's causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database. (was: In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As itis causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database.) > Provide custom table filter for seeding and cleaning databases > -------------------------------------------------------------- > > Key: ARQ-1664 > URL: https://issues.jboss.org/browse/ARQ-1664 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As it's causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 27 12:23:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Thu, 27 Feb 2014 12:23:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-1572 started by Bartosz Majsak. > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 27 15:51:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Thu, 27 Feb 2014 15:51:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948783#comment-12948783 ] Bartosz Majsak commented on ARQ-1572: ------------------------------------- This will work nicely for JARs and WARs, but not for EARs, as there is no 'global classloader' for the ear package as far as I can say. I will keep it as jar in the lib/ folder with the fixed name, eg. 'arquillian-persistence-datasets.jar'. Would it work for you? > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 27 16:21:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Thu, 27 Feb 2014 16:21:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948786#comment-12948786 ] Bartosz Majsak commented on ARQ-1572: ------------------------------------- I could try sth like {code:xml} lib/datasets {code} in application.xml but it's too much manipulation of the test archive and it is not sure it will work everywhere. It certainly won't on [AS7|https://community.jboss.org/message/630869] or [Wildfly|https://issues.jboss.org/browse/WFLY-29]. > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 03:51:47 2014 From: issues at jboss.org (Bernard Labno (JIRA)) Date: Fri, 28 Feb 2014 03:51:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948865#comment-12948865 ] Bernard Labno commented on ARQ-1572: ------------------------------------ If it won't work with AS7 or Wildfly, then let's forget about that and stay with a workaround. But if we can have a fixed name, like arquillian-persistence-datasets.jar, then I can enhance jrebel extension so that it could add auto generated rebel.xml to that archive. > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 03:59:50 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 03:59:50 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948871#comment-12948871 ] Bartosz Majsak commented on ARQ-1572: ------------------------------------- It will work for WAR and that's what I have implemented already. Another approach for handling EAR would be to put the jar as exploded archive in lib directory. If that makes sense I will make it happen but we well need to fix few small things here and there. > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:07:49 2014 From: issues at jboss.org (Bernard Labno (JIRA)) Date: Fri, 28 Feb 2014 04:07:49 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948874#comment-12948874 ] Bernard Labno commented on ARQ-1572: ------------------------------------ But jrebel extensions would still have to add rebel.xml to that exploded archive, wouldn't it? > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:13:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 04:13:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948871#comment-12948871 ] Bartosz Majsak edited comment on ARQ-1572 at 2/28/14 4:13 AM: -------------------------------------------------------------- It will work for WAR and that's what I have implemented already. Another approach for handling EAR would be to put the jar as exploded archive in lib directory. If that makes sense I will make it happen but we will need to fix few small things here and there. was (Author: bmajsak): It will work for WAR and that's what I have implemented already. Another approach for handling EAR would be to put the jar as exploded archive in lib directory. If that makes sense I will make it happen but we well need to fix few small things here and there. > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:15:51 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 04:15:51 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948875#comment-12948875 ] Bartosz Majsak commented on ARQ-1572: ------------------------------------- That's right, unless (taken from jrebel guide): "your container supports APP-INF/classes you may also add a rebel.xml to that folder and mount classes and resources that belong to the EAR as a whole." > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:19:47 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 04:19:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948876#comment-12948876 ] Bartosz Majsak commented on ARQ-1572: ------------------------------------- So the conclusion will be: * JAR and WAR will have it flattened (included in the test archive), so that JRebel works out of the box * For EAR we have {{arquillian-persistence-datasets.jar}} as regular (not exploded) archive. Does that sounds good enough? > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:21:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 04:21:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948876#comment-12948876 ] Bartosz Majsak edited comment on ARQ-1572 at 2/28/14 4:20 AM: -------------------------------------------------------------- So the conclusion will be: * JAR and WAR will have it flattened (included in the test archive), so that JRebel works out of the box * For EAR we have {{arquillian-persistence-datasets.jar}} as regular (not exploded) archive in the {{lib/}} folder in the root of the archive. Does it sounds good enough? was (Author: bmajsak): So the conclusion will be: * JAR and WAR will have it flattened (included in the test archive), so that JRebel works out of the box * For EAR we have {{arquillian-persistence-datasets.jar}} as regular (not exploded) archive. Does that sounds good enough? > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:21:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 04:21:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948876#comment-12948876 ] Bartosz Majsak edited comment on ARQ-1572 at 2/28/14 4:20 AM: -------------------------------------------------------------- So the conclusion will be: * JAR and WAR will have it flattened (included in the test archive), so that JRebel works out of the box * For EAR we have {{arquillian-persistence-datasets.jar}} as regular (not exploded) archive in the {{lib/}} folder in the root of the archive. Does it sound good enough? was (Author: bmajsak): So the conclusion will be: * JAR and WAR will have it flattened (included in the test archive), so that JRebel works out of the box * For EAR we have {{arquillian-persistence-datasets.jar}} as regular (not exploded) archive in the {{lib/}} folder in the root of the archive. Does it sounds good enough? > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:23:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 04:23:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948875#comment-12948875 ] Bartosz Majsak edited comment on ARQ-1572 at 2/28/14 4:21 AM: -------------------------------------------------------------- That's right, unless (taken from [http://zeroturnaround.com/software/jrebel/learn/how-to-configure-rebel-xml/|JRebel guide]): "your container supports APP-INF/classes you may also add a rebel.xml to that folder and mount classes and resources that belong to the EAR as a whole." was (Author: bmajsak): That's right, unless (taken from jrebel guide): "your container supports APP-INF/classes you may also add a rebel.xml to that folder and mount classes and resources that belong to the EAR as a whole." > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:23:48 2014 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 28 Feb 2014 04:23:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948875#comment-12948875 ] Bartosz Majsak edited comment on ARQ-1572 at 2/28/14 4:22 AM: -------------------------------------------------------------- That's right, unless (taken from [JRebel guide|http://zeroturnaround.com/software/jrebel/learn/how-to-configure-rebel-xml/]): "your container supports APP-INF/classes you may also add a rebel.xml to that folder and mount classes and resources that belong to the EAR as a whole." was (Author: bmajsak): That's right, unless (taken from [http://zeroturnaround.com/software/jrebel/learn/how-to-configure-rebel-xml/|JRebel guide]): "your container supports APP-INF/classes you may also add a rebel.xml to that folder and mount classes and resources that belong to the EAR as a whole." > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 04:47:47 2014 From: issues at jboss.org (Bernard Labno (JIRA)) Date: Fri, 28 Feb 2014 04:47:47 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948884#comment-12948884 ] Bernard Labno commented on ARQ-1572: ------------------------------------ Sounds perfect. > Marry Persistence and JRebel extensions > --------------------------------------- > > Key: ARQ-1572 > URL: https://issues.jboss.org/browse/ARQ-1572 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6 > Reporter: Bernard Labno > Assignee: Bartosz Majsak > Fix For: persistence_1.0.0.next > > > JRebel extension currently does not pick up changes in datasets. > Here is how it works: > If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once. > JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*. > Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel. > Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions. > It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 06:27:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 28 Feb 2014 06:27:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-422) Regression in request guard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-422: ------------------------------ Assignee: (was: Luk?? Fry?) > Regression in request guard > --------------------------- > > Key: ARQGRA-422 > URL: https://issues.jboss.org/browse/ARQGRA-422 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.1.Final > Environment: RichFaces 5.0.0-SNAPSHOT > Arquillian Core 1.1.2.Final > Arquillian Drone 1.2.3.Final > Arquillian Graphene 2.0.1.Final > Selenium 2.39.0 > Reporter: Pavol Pitonak > Priority: Blocker > > I have a simple page with two inputs, a submit button and two notify messages (one for each input) - > https://github.com/richfaces/richfaces-qa/blob/requestGuardReproducer/metamer/application/src/main/webapp/components/richNotifyMessage/guardReproducer.xhtml > When you guard ajax request when button is clicked, it fails with timeout: > {code} > org.openqa.selenium.TimeoutException: Timed out after 2 seconds waiting for org.jboss.arquillian.graphene.guard.RequestGuardFactory$RequestIsDone at 19eda624 > {code} > * when you run test (in Steps to Reproduce) all three tests fail on request guard (guarding Ajax request) > * it doesn't matter how WebElement is obtained (WebDriver.find, \@FindBy or \@Page > * these tests fail only when two validation errors are on page, i.e. when two notifyMessage components are displayed > ** e.g. change value of second input from 888 to 8 in guardReproducer.xhtml and it will work > * worked fine with Graphene 2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 28 06:27:48 2014 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Fri, 28 Feb 2014 06:27:48 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-422) Regression in request guard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-422: --------------------------------- Assignee: Juraj H?ska Juraj, could you please look at what happens here? If you need any help or you will have hard time understanding the issue, please let me know. > Regression in request guard > --------------------------- > > Key: ARQGRA-422 > URL: https://issues.jboss.org/browse/ARQGRA-422 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.1.Final > Environment: RichFaces 5.0.0-SNAPSHOT > Arquillian Core 1.1.2.Final > Arquillian Drone 1.2.3.Final > Arquillian Graphene 2.0.1.Final > Selenium 2.39.0 > Reporter: Pavol Pitonak > Assignee: Juraj H?ska > Priority: Blocker > > I have a simple page with two inputs, a submit button and two notify messages (one for each input) - > https://github.com/richfaces/richfaces-qa/blob/requestGuardReproducer/metamer/application/src/main/webapp/components/richNotifyMessage/guardReproducer.xhtml > When you guard ajax request when button is clicked, it fails with timeout: > {code} > org.openqa.selenium.TimeoutException: Timed out after 2 seconds waiting for org.jboss.arquillian.graphene.guard.RequestGuardFactory$RequestIsDone at 19eda624 > {code} > * when you run test (in Steps to Reproduce) all three tests fail on request guard (guarding Ajax request) > * it doesn't matter how WebElement is obtained (WebDriver.find, \@FindBy or \@Page > * these tests fail only when two validation errors are on page, i.e. when two notifyMessage components are displayed > ** e.g. change value of second input from 888 to 8 in guardReproducer.xhtml and it will work > * worked fine with Graphene 2.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira