October 2015 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen edited comment on ARQ-1991 at 10/9/15 2:50 PM: ------------------------------------------------------------- > I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. I would have expected the same, and I would assume the weld-core test suite would see a lot of strange behavior if that was not the case... Could you provide an example of this? was (Author: aslak): > I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. I would have expected the same, and I would assume the weld-core test suite would see a lot of strange behavior of that was not the case... Could you provide an example of this? > Weld EE embedded container leaks extension configuration > -------------------------------------------------------- > > Key: ARQ-1991 > URL: https://issues.jboss.org/browse/ARQ-1991 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR9 > Reporter: John Ament > > I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module. > The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great). > It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1991: ------------------------------------ > I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. I would have expected the same, and I would assume the weld-core test suite would see a lot of strange behavior of that was not the case... Could you provide an example of this? > Weld EE embedded container leaks extension configuration > -------------------------------------------------------- > > Key: ARQ-1991 > URL: https://issues.jboss.org/browse/ARQ-1991 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR9 > Reporter: John Ament > > I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module. > The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great). > It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen updated ARQ-1991: ------------------------------- Component/s: Weld Containers > Weld EE embedded container leaks extension configuration > -------------------------------------------------------- > > Key: ARQ-1991 > URL: https://issues.jboss.org/browse/ARQ-1991 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR9 > Reporter: John Ament > > I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module. > The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great). > It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1991?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen updated ARQ-1991: ------------------------------- Affects Version/s: weld_1.0.0.CR9 > Weld EE embedded container leaks extension configuration > -------------------------------------------------------- > > Key: ARQ-1991 > URL: https://issues.jboss.org/browse/ARQ-1991 > Project: Arquillian > Issue Type: Bug > Affects Versions: weld_1.0.0.CR9 > Reporter: John Ament > > I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module. > The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great). > It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1991) Weld EE embedded container leaks extension configuration

by John Ament (JIRA)

John Ament created ARQ-1991: ------------------------------- Summary: Weld EE embedded container leaks extension configuration Key: ARQ-1991 URL: https://issues.jboss.org/browse/ARQ-1991 Project: Arquillian Issue Type: Bug Reporter: John Ament I have a maven project that leverages arquillian tests for multiple unit cases. One for validators and another for DeltaSpike Data module. The DeltaSpike Data module runs first, followed by the validator one (just happens to be that order, no specific required order). The validator one includes a class deactivator extension that disables an extension on boot. The data module one didn't have this. We began seeing that the data test would pass but the validator suddenly fail. Adding our deactivator to the data module test caused the validator test to suddenly work (this was great). It appears that the CDI extensions provided by the archive are only processed once, I would expect that they get processed per deployment as each deployment archive is run independently at the unit level. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-483?page=com.atlassian.jira.plugin... ] Aslak Knutsen updated ARQGRA-483: --------------------------------- Description: Both Graphene and Warp attempt to override the default Core URLResourceProvider. Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. Technically the two URLs used here could be different: {code} @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { } {code} BaseURL could be proxied and the URL used by InitialPage not, or the other way around. Graphene sets up it's ContextRootStore with which ever URL was provided last; https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/ma... Core will do the opposite, which ever comes first. When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. This seems to be a good test case currently: {code} @Drone private WebDriver driver; @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); } {code} Currently one will show 'proxy-port' and the other '8080'. This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. was: Both Graphene and Warp attempt to override the default Core URLResourceProvider. Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. Technically the two URLs used here could be different: {code} @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { } {code} BaseURL could be proxied and the URL used by InitialPage not, or the other way around. Graphene sets up it's ContextRootStore with which ever URL was provided last; https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/ma... Core will do the opposite, which ever comes first. When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > @Location might use the Wrong URL when used with Warp > ------------------------------------------------------ > > Key: ARQGRA-483 > URL: https://issues.jboss.org/browse/ARQGRA-483 > Project: Arquillian Graphene > Issue Type: Bug > Components: integration > Affects Versions: 2.1.0.Alpha2 > Reporter: Aslak Knutsen > > Both Graphene and Warp attempt to override the default Core URLResourceProvider. > Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. > When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. > Technically the two URLs used here could be different: > {code} > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > } > {code} > BaseURL could be proxied and the URL used by InitialPage not, or the other way around. > Graphene sets up it's ContextRootStore with which ever URL was provided last; > https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/ma... > Core will do the opposite, which ever comes first. > When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. > This seems to be a good test case currently: > {code} > @Drone > private WebDriver driver; > > @ArquillianResource > private URL baseURL; > > @Test @RunAsClient > public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { > Assert.assertEquals(baseURL.getPort(), new URL(driver.getCurrentUrl()).getPort()); > } > {code} > Currently one will show 'proxy-port' and the other '8080'. > This has to do with the dependency order. If you place Graphene before Warp in the POM then Graphene will work because Warp's ProxyURLProvider is the last provider, if you place Warp before Graphene you should see this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-483) @Location might use the Wrong URL when used with Warp

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQGRA-483: ------------------------------------ Summary: @Location might use the Wrong URL when used with Warp Key: ARQGRA-483 URL: https://issues.jboss.org/browse/ARQGRA-483 Project: Arquillian Graphene Issue Type: Bug Components: integration Affects Versions: 2.1.0.Alpha2 Reporter: Aslak Knutsen Both Graphene and Warp attempt to override the default Core URLResourceProvider. Warp has the ProxyURLProvider and Graphene the CustomizableURLResourceProvider. When both Graphene and Warp is on classpath it becomes unpredictable who will actually win. Technically the two URLs used here could be different: {code} @ArquillianResource private URL baseURL; @Test @RunAsClient public void shouldBeAbleToStoreConference(@InitialPage ConferencePage page) throws Exception { } {code} BaseURL could be proxied and the URL used by InitialPage not, or the other way around. Graphene sets up it's ContextRootStore with which ever URL was provided last; https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/ma... Core will do the opposite, which ever comes first. When Graphene resolves the 'non-proxied' URL, Warp will eventually time out waiting for a reply as it never got to setup and sync. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1986) Jacoco extesion creates empty manifest entries removing the ones present in the archive

by Alexandros Trifyllis (JIRA)

[ https://issues.jboss.org/browse/ARQ-1986?page=com.atlassian.jira.plugin.s... ] Alexandros Trifyllis commented on ARQ-1986: ------------------------------------------- I would try to recreate the issue with a simple pom because mine is quite complicated. If I can't recreate I will post the original one. > Jacoco extesion creates empty manifest entries removing the ones present in the archive > --------------------------------------------------------------------------------------- > > Key: ARQ-1986 > URL: https://issues.jboss.org/browse/ARQ-1986 > Project: Arquillian > Issue Type: Bug > Components: Extension - Jacoco > Affects Versions: jacoco_1.0.0.Alpha8 > Reporter: Alexandros Trifyllis > Priority: Minor > > The ShrinkWrap generated war file contains an empty MANIFEST.MF instead of the one specified during archive creation -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1988) Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1988?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen updated ARQ-1988: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Warp HTTPCore 4.3 dependency conflict with latest Drone Alpha5 > -------------------------------------------------------------- > > Key: ARQ-1988 > URL: https://issues.jboss.org/browse/ARQ-1988 > Project: Arquillian > Issue Type: Component Upgrade > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7 > Reporter: Aslak Knutsen > Fix For: warp_1.0.0.Beta1 > > > Warp needs to upgrade to HTTPCore 4.4.3 to be compatible with Drone 2.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1990) Should not export tests classified dependencies in compile scope

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1990?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen updated ARQ-1990: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: recorder_1.1.0.Alpha4 Resolution: Done > Should not export tests classified dependencies in compile scope > ---------------------------------------------------------------- > > Key: ARQ-1990 > URL: https://issues.jboss.org/browse/ARQ-1990 > Project: Arquillian > Issue Type: Bug > Components: Extension - Recorder > Affects Versions: recorder_1.1.0.Alpha3 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: recorder_1.1.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues October 2015