Thanks, Rebecca. Ok, I'll take a look at ClientInvocation.


On 05/23/2016 12:31 PM, Rebecca Searls wrote:
I don't find any deprecated Apache classes we are trying to cleanup being used by the submitted classes.
The code is using a couple of Apache classes with deprecated methods but nothing significant and I don't
see this code using those methods.

resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/internal/ClientInvocation.java
is changed in a significant way.  It would probably be better for someone more familiar with this
class to review the changes.

A testcase is provided so that is helpful.

If all looks good I suggest merging it into some build.  The Apache work can merge with it at a later time. 


----- Original Message -----
From: "Rebecca Searls" <rsearls@redhat.com>
To: "Ron Sigal" <rsigal@redhat.com>
Cc: resteasy-dev@lists.jboss.org
Sent: Monday, May 23, 2016 11:51:40 AM
Subject: Re: [resteasy-dev] Proposed changes to org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine

Thanks,  I'll take a look.


----- Original Message -----
From: "Ron Sigal" <rsigal@redhat.com>
To: "Rebecca Searls" <rsearls@redhat.com>
Cc: resteasy-dev@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@redhat.com>
To: resteasy-dev@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@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)

_______________________________________________
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)


_______________________________________________
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)