[resteasy-dev] Proposed changes to org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine

[Rebecca Searls]

Thanks,  I'll take a look.


----- Original Message -----
> From: "Ron Sigal" <rsigal at redhat.com>
> To: "Rebecca Searls" <rsearls at redhat.com>
> Cc: resteasy-dev at lists.jboss.org
> Sent: Monday, May 23, 2016 11:16:20 AM
> Subject: Re: [resteasy-dev] Proposed changes to org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine
> 
> By the way, there's also a Pull Request related to HttpClient:
> https://github.com/resteasy/Resteasy/pull/540. I think it's the only
> outstanding PR I haven't looked into.
> 
> -Ron
> 
> 
> On 05/17/2016 06:09 AM, Rebecca Searls wrote:
> >
> > ----- Original Message -----
> >> From: "Ron Sigal" <rsigal at redhat.com>
> >> To: resteasy-dev at lists.jboss.org
> >> Sent: Monday, May 16, 2016 9:26:36 PM
> >> Subject: Re: [resteasy-dev] Proposed changes to
> >> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine
> >>
> >> 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
> > I don't see this one as directly related to RESTEASY-1357.  Its a secondary
> > issue.
> >
> >> * https://issues.jboss.org/browse/RESTEASY-1089
> > This one is directly related.  I've linked it to the RESTEASY-1357
> >
> >> * https://issues.jboss.org/browse/RESTEASY-1192
> > I think this is a secondary issue as well.
> >> -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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/resteasy-dev
> >> _______________________________________________
> >> resteasy-dev mailing list resteasy-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/resteasy-dev
> >>
> >> --
> >> My company's smarter than your company (unless you work for Red Hat)
> >>
> >> _______________________________________________
> >> resteasy-dev mailing list
> >> resteasy-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/resteasy-dev
> >>
> 
> --
> My company's smarter than your company (unless you work for Red Hat)
> 
>