]
Lukáš Fryč updated ARQGRA-483:
------------------------------
Fix Version/s: 2.1.0.Beta1
(was: 2.1-Tracking)
@Location might use the Wrong URL when used with Warp
------------------------------------------------------
Key: ARQGRA-483
URL:
https://issues.jboss.org/browse/ARQGRA-483
Project: Arquillian Graphene
Issue Type: Bug
Components: integration
Affects Versions: 2.1.0.Alpha2
Reporter: Aslak Knutsen
Fix For: 2.1.0.Beta1
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.