@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 Assignee: Matous Jobanek 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.