]
Matous Jobanek commented on ARQ-1952:
-------------------------------------
Hi, I don't want to say that it is a dead project, it just relies on a community
effort. The problem is that we don't have enough time and resources as we would like
to have to keep the development of the project alive and to fix all issues that has been
raised. We would be delighted to have some more contributions there, so if you are
interested feel free to send a PR or ask questions about implementation details. We would
really appreciate any input from your or anyone else's side. If you just want to
release a new version of Warp containing the latest fixes and improvements, then drop me
an email or create an issue on github and I'll do it ASAP.
Thanks
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
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.