Hi Rebecca,

Following up on our discussion during today's meeting, changing that constructor would introduce a new behavior that may break someone's code. That was the point of the discussion in RESTEASY-975. So we have to come to some decision about how to manage changes like this. Should we have, as you suggested, a 3.0.x branch that maintains the current behavior, so that a change like this can be introduced into master (or whatever ends up serving as master for 3.1.x)? My concern is that fixes for older bugs [not that we will ever introduce any new bugs ;-) ] will have to be applied to two branches. More work, but now we have more people. I don't know. Is that considered a best practice? Just wondering.

By the way, other issues that may (or may not) be related:

 * https://issues.jboss.org/browse/RESTEASY-906
 * https://issues.jboss.org/browse/RESTEASY-1089
 * https://issues.jboss.org/browse/RESTEASY-1192
 
-Ron


On 05/15/2016 11:36 PM, Weinan Li wrote:
Hi Rebecca,

Here are two relative issues maybe you'll be interested in:

https://issues.jboss.org/browse/RESTEASY-975
https://issues.jboss.org/browse/RESTEASY-1023

- Weinan Li


On May 16, 2016, at 4:01 AM, Rebecca Searls <rsearls@redhat.com> wrote:


I'm cleaning up the deprecated apache classes in resteasy-client.
I am currently working on org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.
One of four ApacheHttpClient4Engine constructor methods is using the deprecated class 
org.apache.http.impl.client.DefaultHttpClient.

  public ApacheHttpClient4Engine()
  {
     this.httpClient = new DefaultHttpClient();
     this.createdHttpClient = true;
  }

Apache's (version 4.3) requirement is to use a HttpClientBuilder to generated a new HttpClient
object.  I can generated the HttpClient using Builder, HOWEVER doing so will mean a HttpHost 
can never be assigned to the this.httpClient object. 

I propose doing the following to address this.

   1) Implement the no-arg constructor using the new Builder procedure.
      Adding Javadoc comments of the restriction to this constructor. 
   2) Create a new constructor method that requires the input argument of HttpHost
       and generates the HttpClient using the Builder procedure.



ApacheHttpClient4Engine methods getDefaultProxy setDefaultProxy are obsolete.
A HttpPort object can not longer be set or retrieved from HttpClient using 
org.apache.http.params.HttpParams. 

I don't find any Resteasy code calling getDefaultProxy.  There is only 1 call
to setDefaultProxy which is easily addressed.
Since both methods are public, I propose the following changes.

1) Tag both methods deprecated.
2) getDefaultProxy() will always return NULL;
3) setDefaultProxy() will do nothing.
4) Add Javadoc to both methods.

Comments and suggestions on these proposals would be appreciated.
_______________________________________________
resteasy-dev mailing list
resteasy-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev


_______________________________________________
resteasy-dev mailing list
resteasy-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev


-- 
My company's smarter than your company (unless you work for Red Hat)