I do not think it is necessary to start right with replacing internals of HttpJsonHelper with JAX-RS Client API.
We can start by simply moving the internal code (HttpJsonHelperImpl.requestString(..)) outside of HttpJsonHelper and injecting it statically without a failing requirement.
This change makes a good example for my intention. Since the injection optional, HttpJsonHelper act as usual unless HttpHelper is injected statically by
the target assembly.
https://github.com/tareqhs/che-core/commit/bacf489c812de504efa3382740b55bf9b1c633d5
thank you
Tareq Sharafy
From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Yevhenii Voevodin
Sent: Wednesday 09 December 2015 17:55
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Outbound HTTP requests in Che server-side
If i understand you correct, by 'common code for HTTP requests' you mean JAX-RS Client API inside of the HttpJsonHelper/HttpJsonRequest.
So it is nice point and totally makes sense, i think it will be done as soon as we integrate JAX-RS Client API to our infrastructure.
If you wish you can do your own implementation of the HttpJsonRequest as you mentioned before.
On Wed, Dec 9, 2015 at 4:50 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi,
Please allow me to clarify.
My intention is not to have a better way for conveniently sending/retrieving JSON data, but rather
to manage the requests themselves regardless of whether JSONs are being sent/retrieved. HttpJsonHelper itself is effectively many tiny wrappers this sink into a single function that sends a general request and receives its response – this internal function
is the place I am discussing here. Having a common code for HTTP requests that is reused by that core function inside HttpJsonHelper will solve the issues I described earlier.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Yevhenii Voevodin
Sent: Wednesday 09 December 2015 16:21
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Outbound HTTP requests in Che server-side
> Still, it does not allow intervening the request lifecycle which is the main point of my message
We tried to build conceptually the same thing as HttpJsonHelper, so it doesn't provide methods
for appropriate request managing e.g. you cant set headers or use body different from JsonSerializable.
I think that if you want to get content different from json or you don't want to use authentication
header, then you don't need HttpJsonRequest, or it won't be JSON request any more.
We planned to use JAX-RS Client API in the future to cover the use-cases which you discussed.
> Is this planned to replace the scattered code the copies HttpJsonHelper
Yes the plan is replace usage of HttpJsonHelper and deprecate it.
On Wed, Dec 9, 2015 at 3:55 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi Yevhenii,
I've inspected your commit and indeed it makes a good start by relying on injection instead of
static method. Still, it does not allow intervening the request lifecycle which is the main point of my message. I guess we can solve this by having an alternative implementation of HttpJsonRequestFactory.
Is this planned to replace the scattered code the copies HttpJsonHelper? (e.g. RemoteRunnerProcess.doRequest)
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Yevhenii Voevodin
Sent: Wednesday 09 December 2015 14:53
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Outbound HTTP requests in Che server-side
Yes HttpJsonHelper is not convinient to use and test, and because of this we added new builder-like interface-based analogue
HttpJsonRequest. The only problem here is that it is in 4.0 branch, but there is no problem to port it into the master.
We have some thoughts about JAX-RS Client API, and also wanted to integrate it, but for now we are okay with HttpJsonRequest, and we postponed JAX-RS Client API integration for
the next time.
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
|
