[
https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s...
]
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/...]
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/blo...]
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-grap...]
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/c8ff5a2096...],
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)