[JBoss JIRA] (ARQ-1959) Arquillian Governor doesn't work together with RestEasy REST client
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1959?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic commented on ARQ-1959:
----------------------------------------
Until you do not point me to working JIRA client which would not clash with your RestEasy dependency, I am not able to do anything about it.
> Arquillian Governor doesn't work together with RestEasy REST client
> -------------------------------------------------------------------
>
> Key: ARQ-1959
> URL: https://issues.jboss.org/browse/ARQ-1959
> Project: Arquillian
> Issue Type: Bug
> Affects Versions: 1.0.0.Alpha2
> Reporter: Petr Mensik
>
> Project which uses REST API (with RestEasy implementation) doesn't work with Governor-Jira because it has it's own com.atlassian.jira.rest.client implementation which misses some features. If you exclude this dependency then you are unable to use the extension in your project (ClassNotFoundException during runtime, obviously).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (ARQ-1959) Arquillian Governor doesn't work together with RestEasy REST client
by Petr Mensik (JIRA)
Petr Mensik created ARQ-1959:
--------------------------------
Summary: Arquillian Governor doesn't work together with RestEasy REST client
Key: ARQ-1959
URL: https://issues.jboss.org/browse/ARQ-1959
Project: Arquillian
Issue Type: Bug
Affects Versions: 1.0.0.Alpha2
Reporter: Petr Mensik
Project which uses REST API (with RestEasy implementation) doesn't work with Governor-Jira because it has it's own com.atlassian.jira.rest.client implementation which misses some features. If you exclude this dependency then you are unable to use the extension in your project (ClassNotFoundException during runtime, obviously).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one
by Pëtr Andreev (JIRA)
[ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s... ]
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-...] 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-...] 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)
9 years, 6 months