[jbosstools-dev] Refactoring openshift-restclient-java to depend upon OkHttp client

[Max Rydahl Andersen]

On 27 Jun 2016, at 13:55, Jeff Cantrill wrote:

> On Sun, Jun 26, 2016 at 5:11 AM, Max Rydahl Andersen 
> <manderse at redhat.com>
> wrote:
>
>>
>> The current release of the openshift-restclient-java, for not so 
>> obvious
>>> reasons, depends on no less then 3 libraries to provide the 
>>> underlying
>>> communication to the cluster server.  The following PR
>>> https://github.com/openshift/openshift-restclient-java/pull/179 
>>> unifies
>>> this dependency to a single client which is based on OkHttp.  We are
>>> looking to make this change to:
>>>
>>> * Provide a common way to make REST calls
>>> * Simplify the authorization semantics to an openshift cluster
>>> * Simplify the pattern of making REST calls over what is done today
>>> * In future, take advantage of its SPDY support to move away from 
>>> the oc
>>> binary dependency
>>> * Put us in a better position to move to the Fabric8 client (if that 
>>> ever
>>> happens)
>>>
>>> Any comments or objects are welcome
>>>
>>
>> 0) "In future" about SPDY - what does that mean ? Can OKhttp already 
>> talk
>> with SPDY
>>    on Java 8 without changing the bootclasspath ?
>>
>> This client already supports both SPDY and HTTP/2.  I plan to do 
>> further
> tests to verify what can be done with the SPDY support but 
> implementing
> puts us in no worse of a position now IMO.

How does it support it ? If it requires changing the bootclasspath it is 
not
going to work anyway.

>> 1) did you look at the work Stuart Douglas did ? (see mail thread: 
>> "ALPN
>> in Java")
>>    Would that be a better option for SPDY ? That would work for Java 
>> 8 at
>> least.
>>
>
> I think if we EVER anticipate unifying a client with fabric8 our best
> option is to start with dependency on some of the libraries they use.
> OkHttp has SPDY support which I believe is just a matter of 
> understanding
> what we can do with it.  At a minimum, this library is significantly 
> easier
> IMO to use then either jetty, apache client, or the home grown client 
> we
> were using.

okey, but that does not matter if this library requires changing 
bootclasspath
when using Java 8.

>> 2) will this integrate with use of proxy settings etc. configured in
>> Eclipse ?
>>    that is what ECF today does for normal http URL connections, if 
>> you are
>> using
>>    a separate library my guess is that it is ignoring proxy and other 
>> auth
>> setup
>>    done in eclipse, but I could be wrong.
>>
>> It has proxy support as well.  I will add that to my check list of 
>> items
> to verify.

Okey, but without that I would say its a nogo since we had more than a 
big share
of issues in past of users having to configure proxies to use openshift
and the "fix" for that was users to setup proxies in eclipse.

Btw. it is probably possible to add that support but something that 
should be
part of being fixed before including in a release.

/max
http://about.me/maxandersen