[
https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s...
]
Pëtr Andreev commented on ARQ-1952:
-----------------------------------
@[~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-...]
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)