[arquillian-issues] [JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one

[Pëtr Andreev (JIRA)]

    [ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070110#comment-13070110 ] 

Pëtr Andreev commented on ARQ-1952:
-----------------------------------

I think, I can describe what causing the problem: the new feature for customizable URLs was introduced with [ARQGRA-374|https://issues.jboss.org/browse/ARQGRA-374]. The [GrapheneExtension|https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/GrapheneExtension.java#L85-90] overrides the default _URLResourceProvider_. It works well until Warp comes into the play (which is the case while ITesting the RichFaces): the [WarpExtension|https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/WarpExtension.java#L75-76] overrides the default _URLResourceProvider_ too. So actually both URLProviders coexist in the ServiceRegistry. What happens during the Warp request processing is: while storing the location in [ContextRootStoreInitializer|https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/main/java/org/jboss/arquillian/graphene/location/ContextRootStoreInitializer.java#L52-56]  the _ServiceRegistryLoader_ is asked for all available URLProviders and both, the Warp AND Graphene ones, _canProvide_ URL. Since the order of the _Set_ entries returned by _ServiceLoader_ depends on _weather_, the Graphene` _CustomizableURLProvider_ returns the non-proxied URL (port 8080).
The suggested solution can be found [here|https://github.com/petrandreev/arquillian-graphene/commit/c8ff5a2096174ab68e618adf97877af1b2829676], it skips the registration of any _CustomizableURLResourceProvider_s in the Warp environment. I think this should not interfere with use cases in the standalone Graphene environment. I can provide a PR.

> Warp requests hit the application port instead of LittleProxy`s one
> -------------------------------------------------------------------
>
>                 Key: ARQ-1952
>                 URL: https://issues.jboss.org/browse/ARQ-1952
>             Project: Arquillian
>          Issue Type: Bug
>          Components: Extension - Warp
>    Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1
>         Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11
>            Reporter: Pëtr Andreev
>         Attachments: ARQ-1952-failure.log, ARQ-1952-success.log
>
>
> Warp observer intermittently fails while inspecting the requests with:
> "There were no requests matched by observer \[containsParameter(XXXX)\] ".
> The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful  and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)