On May 16, 2016, at 4:01 AM, Rebecca Searls <rsearls(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

On May 17, 2016, at 9:26 AM, Ron Sigal <rsigal(a)redhat.com&gt; wrote: 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(a)redhat.com&gt; >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/resteasy-dev > > _______________________________________________ > resteasy-dev mailing list > > resteasy-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

> 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)? I'm fine with this. Let's use the minor version change for this. On a related topic, we should keep track of changes like this so that we can later prepare migration notes (when we'll be ready for releasing next minor).

Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss

_______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

I'm just curious. After tagging an API deprecated, how many product versions do we release before actually removing the API? ----- Original Message ----- > From: "Alessio Soldano" <asoldano(a)redhat.com&gt; > To: resteasy-dev(a)lists.jboss.org > Sent: Tuesday, May 17, 2016 3:43:23 AM > Subject: Re: [resteasy-dev] Proposed changes to org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine > > Il 17/05/2016 03:26, Ron Sigal ha scritto: > > > 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)? I'm fine with this. Let's use the minor version change > for this. On a related topic, we should keep track of changes like this so > that we can later prepare migration notes (when we'll be ready for releasing > next minor). > > Cheers > Alessio > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > resteasy-dev mailing list > resteasy-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/resteasy-dev >

From: "Ron Sigal" <rsigal(a)redhat.com&gt; To: resteasy-dev(a)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

* 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(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev _______________________________________________ resteasy-dev mailing list resteasy-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

From: "Ron Sigal" <rsigal(a)redhat.com&gt; To: "Rebecca Searls" <rsearls(a)redhat.com&gt; Cc: resteasy-dev(a)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(a)redhat.com&gt; >> To: resteasy-dev(a)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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/resteasy-dev >> _______________________________________________ >> resteasy-dev mailing list resteasy-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/resteasy-dev >> -- My company's smarter than your company (unless you work for Red Hat)

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(a)redhat.com&gt; > To: "Ron Sigal" <rsigal(a)redhat.com&gt; > Cc: resteasy-dev(a)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(a)redhat.com&gt; >> To: "Rebecca Searls" <rsearls(a)redhat.com&gt; >> Cc: resteasy-dev(a)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(a)redhat.com&gt; >>>> To: resteasy-dev(a)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(a)redhat.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/resteasy-dev >>>> _______________________________________________ >>>> resteasy-dev mailing list resteasy-dev(a)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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/resteasy-dev >