[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=13081317#comment-13081317 ] 

Pëtr Andreev edited comment on ARQ-1952 at 6/18/15 4:11 PM:
------------------------------------------------------------

[~Lukáš Fryč] concerning ??we would tie Graphene implementation to Warp's internals??- I don`t get it at all- my intention was clearly decouple the [Customizable|https://github.com/petrandreev/arquillian-graphene/blob/ARQ-1952/impl/src/main/java/org/jboss/arquillian/graphene/location/CustomizableURLResourceProvider.java] from anything else, even from the ARQ core` URLProvider, not to speak of the Warp. From my point of view the CustomizableURLResourceProvider is only useful in the narrow scope of "deploymentless" environment (which is rather a seldom use case) and should only take care of this not more and not less. The other thing is, that the proposed solution actually requires the rethinking of the  _Provider_ concept in the way that _canProvide_ not just means one can provide instances of class but furthermore considers the current test/arquillian environment. Changing concepts could be risky though... 
The ResourceWapper draft would not work with the current core implementation as far as i could evaluate it, i guess for this the core provider handling should be re-factored a little. Just my two cents (i just don`t want the RF guys to throw out  the Warp tests)...


was (Author: pjotrovsky):
@[~Lukáš Fryč] concerning ??we would tie Graphene implementation to Warp's internals??- I don`t get it at all- my intention was clearly decouple the [Customizable|https://github.com/petrandreev/arquillian-graphene/blob/ARQ-1952/impl/src/main/java/org/jboss/arquillian/graphene/location/CustomizableURLResourceProvider.java] from anything else, even from the ARQ core` URLProvider, not to speak of the Warp. From my point of view the CustomizableURLResourceProvider is only useful in the narrow scope of "deploymentless" environment (which is rather a seldom use case) and should only take care of this not more and not less. The other thing is, that the proposed solution actually requires the rethinking of the  _Provider_ concept in the way that _canProvide_ not just means one can provide instances of class but furthermore considers the current test/arquillian environment. Changing concepts could be risky though... 
The ResourceWapper draft would not work with the current core implementation as far as i could evaluate it, i guess for this the core provider handling should be re-factored a little. Just my two cents (i just don`t want the RF guys to throw out  the Warp tests)...

> 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
>            Assignee: Lukáš Fryč
>             Fix For: warp_1.0.0.Beta1
>
>         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)