Re: [che-dev] Using a JAX-RS client library in Che

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Another approach...that can/could accommodate multiple communications approaches...would be to define a set of service APIs for LSP...i.e. methods, params, and return types, and use ECF's impl of OSGi Remote Services [0] to allow substitution of custom distribution implementations...i.e. one of [1] or new/others.   From what I can tell, this sort of service API (gen from spec) vs distribution system (impl) is already being done by TypeFox, and perhaps others, so it's not a change from what appears to be going on WRT LSP.

This has the side benefit of clearly separating the LSP standardization efforts (service APIs) from any particular implementation, serialization impl, or transport (jsonrpc, jax-rs, mqtt, etc).  See also other benefits as described in [2].

Scott

[0] http://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote_Services
[1] https://wiki.eclipse.org/Distribution_Providers
[2] http://eclipseecf.blogspot.com/2016/05/microservices-granularity-for-internet.html

On 7/29/2016 9:43 AM, Sharafy, Tareq wrote:

Hi Sergii,

 

Thanks for the feedback.

I can suggest a less invasive approach. A general "HttpProvider" issues concrete HTTP requests in Che, with the API:

 

@ImplementedBy(DefaultHttpProvider.class)

public interface HttpProvider {

    HttpResponse request(

      String url,

      int timeout,

      String method,

      InputStream body,

      List<Pair<String, String>> headers,

      List<Pair<String, ?>> queryParams) throws IOException;

}

 

public interface HttpResponse extends AutoCloseable {

    int getResponseCode() throws IOException;

    String getContentType();

    InputStream getStream() throws IOException;

}

 

The API is general enough and can be reused by both DefaultHttpJsonRequest internally and other areas in Che that need general HTTP connections, e.g. sources manager and download plugin.

This still achieves a universally single HTTP flow in Che and allows customized platforms and inject their own HttpProvider implementations.

More importantly, this is completely transparent to the common JSON flows.

 

Thoughts on this?

 

thank you

Tareq Sharafy

 

From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergii Kabashniuk
Sent: Friday 29 July 2016 18:04
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Using a JAX-RS client library in Che

 

Hello Tareq

 

We assume that 99% of our cross-service communications are json based. HttpJsonRequest should cover it perfectly.

In the same time  it might be a couple of services that can't  be covered with HttpJsonRequest. But possible 

conflicts between Jersey and everrest + additional dependencies (that have to be approved by Eclipse BTW ) is not worth 

of that small percent of additional syntax sugar. 

 

On Fri, Jul 29, 2016 at 1:45 AM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:

Hi,

 

I'm inspecting the area of issuing outgoing HTTP calls from inside Che.

We are in a more advanced position now - ditching HttpJsonHelper and replacing it with HttpJsonRequest. But we still have the issue of managing general (non JSON) HTTP requests. Currently we have numerous areas in Che code (both 3.x and 4.x) that create and manipulate URLConnection. Lots of code duplication no central management/filtering.

 

I would like to provide a POC for a general "request factory" that provides and manages standard JAX-RS targets.

https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/package-summary.html

HttpJsonRequest will keep its API but use the more general APIs internally, eventually having a single flow for all out-going HTTP requests in Che.

 

Since Everrest provides server-side JAX-RS only, I have to use one of the available JAX-RS client libraries.

Is it OK to add Jersey Client and use it from Che ?

https://jersey.java.net/documentation/latest/client.html

 

thank you

Tareq Sharafy

Cloud Development Experience | SAP Labs Israel | 15 Hatidhar st, Raanana 43665, Israel

T +972-(0)7-4732-1647 | F +972-(0)9-777-5618

 

_______________________________________________
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