[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
[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
[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
[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
[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
[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
[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