[jira] [Created] (HTTPCORE-468) Allow HttpAsyncService subclasses to customize the HTTP status code

Gary Gregory created HTTPCORE-468: - Summary: Allow HttpAsyncService subclasses to customize the HTTP status code Key: HTTPCORE-468 URL: https://issues.apache.org/jira/browse/HTTPCORE-468 Project:

[jira] [Updated] (HTTPCORE-467) Add getter methods to HttpAsyncService for subclasses to access instance variables

[ https://issues.apache.org/jira/browse/HTTPCORE-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated HTTPCORE-467: -- Description: In order to my {{org.apache.http.nio.protocol.HttpAsyncService}} subclass to be

[jira] [Updated] (HTTPCORE-467) Add getter methods to HttpAsyncService for subclasses to access instance variables

[ https://issues.apache.org/jira/browse/HTTPCORE-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated HTTPCORE-467: -- Description: Add getter methods to {{org.apache.http.nio.protocol.HttpAsyncService}} for

Add getter methods to HttpAsyncService for subclasses to access instance variables

In order to my HttpAsyncService to be coded cleanly, I would like to add getter methods to HttpAsyncService for subclasses to access instance variables: https://issues.apache.org/jira/browse/HTTPCORE-467 Any objections? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java

[jira] [Created] (HTTPCORE-467) Add getter methods to HttpAsyncService for subclasses to access instance variables

Gary Gregory created HTTPCORE-467: - Summary: Add getter methods to HttpAsyncService for subclasses to access instance variables Key: HTTPCORE-467 URL: https://issues.apache.org/jira/browse/HTTPCORE-467

[jira] [Resolved] (HTTPASYNC-122) CloseableHttpAsyncClient executed old versions of requests

[ https://issues.apache.org/jira/browse/HTTPASYNC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan Zimmerman resolved HTTPASYNC-122. Resolution: Not A Problem OK - this was my error. My code was in a loop sending

org.apache.http.nio.protocol.HttpAsyncService.requestReceived(NHttpServerConnection)

Hi, I find it inconvenient that: org.apache.http.nio.protocol.HttpAsyncService.requestReceived(NHttpServerConnection) Does not take an HttpContext argument. I'm not sure there is pretty way to fix this in 4.4.x with BC. I'm not looked at 5.0.x yet. Gary -- E-Mail: garydgreg...@gmail.com |

Re: Git policies and practices

On Mon, May 15, 2017 at 11:59 AM, Gary Gregory wrote: > On Mon, May 15, 2017 at 11:57 AM, Michael Osipov > wrote: > >> Am 2017-05-15 um 20:43 schrieb Gary Gregory: >> >>> On Mon, May 15, 2017 at 11:37 AM, Michael Osipov >>>

[jira] [Updated] (HTTPASYNC-122) CloseableHttpAsyncClient executed old versions of requests

[ https://issues.apache.org/jira/browse/HTTPASYNC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan Zimmerman updated HTTPASYNC-122: --- Attachment: log.txt.zip Sorry - wire was missing. This is the full log. >

Re: Git policies and practices

On Mon, May 15, 2017 at 11:57 AM, Michael Osipov wrote: > Am 2017-05-15 um 20:43 schrieb Gary Gregory: > >> On Mon, May 15, 2017 at 11:37 AM, Michael Osipov >> wrote: >> >> Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski: >>> >>> On Mon, 2017-05-15 at

Re: Git policies and practices

Am 2017-05-15 um 20:43 schrieb Gary Gregory: On Mon, May 15, 2017 at 11:37 AM, Michael Osipov wrote: Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski: On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote: Folks, I have updated the link based on the input and put

[jira] [Updated] (HTTPASYNC-122) CloseableHttpAsyncClient executed old versions of requests

[ https://issues.apache.org/jira/browse/HTTPASYNC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan Zimmerman updated HTTPASYNC-122: --- Attachment: log.txt Here's the log when the problem exhibited. Let me know if this

Re: Git policies and practices

On Mon, May 15, 2017 at 11:37 AM, Michael Osipov wrote: > Am 2017-05-15 um 20:18 schrieb Oleg Kalnichevski: > >> On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote: >> >>> Folks, >>> >>> I have updated the link based on the input and put it onto the wiki: >>>

[Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" for change notification. The "GitGuidelines" page has been changed by MichaelOsipov: https://wiki.apache.org/HttpComponents/GitGuidelines?action=diff=5=6 Comment: Replaced master with release branch

Re: Git policies and practices

Am 2017-05-15 um 20:22 schrieb Oleg Kalnichevski: On Mon, 2017-05-15 at 20:13 +0200, Michael Osipov wrote: Am 2017-05-15 um 19:35 schrieb Gary Gregory: On Mon, May 15, 2017 at 9:34 AM, Michael Osipov

Re: Git policies and practices

Am 2017-05-15 um 20:18 schrieb Gary Gregory: On Mon, May 15, 2017 at 11:13 AM, Michael Osipov wrote: Am 2017-05-15 um 19:35 schrieb Gary Gregory: On Mon, May 15, 2017 at 9:34 AM, Michael Osipov wrote: Folks, I have updated the link based on the

[jira] [Commented] (HTTPASYNC-122) CloseableHttpAsyncClient executed old versions of requests

[ https://issues.apache.org/jira/browse/HTTPASYNC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011049#comment-16011049 ] Oleg Kalnichevski commented on HTTPASYNC-122: - Please attach wire / context log of the

Re: [jira] [Commented] (HTTPCORE-466) Round out the SslContextBuilder by adding missing APIs

On Mon, 2017-05-15 at 18:06 +, Gary Gregory (JIRA) wrote: > [ https://issues.apache.org/jira/browse/HTTPCORE-466?page=com.atl > assian.jira.plugin.system.issuetabpanels:comment- > tabpanel=16011014#comment-16011014 ]  > > Gary Gregory commented on HTTPCORE-466: >

Re: Git policies and practices

On Mon, 2017-05-15 at 20:13 +0200, Michael Osipov wrote: > Am 2017-05-15 um 19:35 schrieb Gary Gregory: > > On Mon, May 15, 2017 at 9:34 AM, Michael Osipov > > > Which of the paths should we pick: > > https://makandracards.com/makandra/527-squash-several-git-commits-i

[jira] [Created] (HTTPASYNC-122) CloseableHttpAsyncClient executed old versions of requests

Jordan Zimmerman created HTTPASYNC-122: -- Summary: CloseableHttpAsyncClient executed old versions of requests Key: HTTPASYNC-122 URL: https://issues.apache.org/jira/browse/HTTPASYNC-122 Project:

Re: Git policies and practices

On Mon, May 15, 2017 at 11:13 AM, Michael Osipov wrote: > Am 2017-05-15 um 19:35 schrieb Gary Gregory: > >> On Mon, May 15, 2017 at 9:34 AM, Michael Osipov >> wrote: >> >> Folks, >>> >>> I have updated the link based on the input and put it onto the

Re: Git policies and practices

On Mon, 2017-05-15 at 18:34 +0200, Michael Osipov wrote: > Folks, > > I have updated the link based on the input and put it onto the wiki: > https://wiki.apache.org/HttpComponents/GitGuidelines > > Here is verbatim copy: > = Typical Issue Workflow = > >   1. Branch off master ({{{git checkout

Re: Git policies and practices

Am 2017-05-15 um 19:35 schrieb Gary Gregory: On Mon, May 15, 2017 at 9:34 AM, Michael Osipov wrote: Folks, I have updated the link based on the input and put it onto the wiki: https://wiki.apache.org/HttpComponents/GitGuidelines Here is verbatim copy: = Typical Issue

[jira] [Commented] (HTTPCORE-466) Round out the SslContextBuilder by adding missing APIs

[ https://issues.apache.org/jira/browse/HTTPCORE-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011012#comment-16011012 ] Gary Gregory commented on HTTPCORE-466: --- {noformat} commit

[jira] [Commented] (HTTPCORE-466) Round out the SslContextBuilder by adding missing APIs

[ https://issues.apache.org/jira/browse/HTTPCORE-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16010998#comment-16010998 ] Gary Gregory commented on HTTPCORE-466: --- OK, I will do it. > Round out the SslContextBuilder by

Re: Git policies and practices

On Mon, May 15, 2017 at 9:34 AM, Michael Osipov wrote: > Folks, > > I have updated the link based on the input and put it onto the wiki: > https://wiki.apache.org/HttpComponents/GitGuidelines > > Here is verbatim copy: > = Typical Issue Workflow = > > 1. Branch off master

Re: Git policies and practices

On Mon, May 15, 2017 at 9:45 AM, Michael Osipov wrote: > Am 2017-05-15 um 18:39 schrieb Gary Gregory: > >> I wonder of all the branches that are effectively temporary should be in a >> "temp/" root to make it obvious this is short term like my >> dev/4.4.x/HTTPCORE-466? Not

Re: Git policies and practices

Am 2017-05-15 um 18:39 schrieb Gary Gregory: I wonder of all the branches that are effectively temporary should be in a "temp/" root to make it obvious this is short term like my dev/4.4.x/HTTPCORE-466? Not great, but maybe less confusing? I don't like that idea because you will never be able

Re: [Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Am 2017-05-15 um 18:59 schrieb Michael Osipov: Am 2017-05-15 um 18:43 schrieb Gary Gregory: Altassian has a plugin to handle (7) IIRC, we use something like that at work but for SVN. The plugin links a JIRA ticket to commits if the commit message includes the string [JIRA-ID]. There is also

Re: [Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Am 2017-05-15 um 18:43 schrieb Gary Gregory: Altassian has a plugin to handle (7) IIRC, we use something like that at work but for SVN. The plugin links a JIRA ticket to commits if the commit message includes the string [JIRA-ID]. There is also Altassian FishEye. I aware of that plugin. In

Re: [Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Altassian has a plugin to handle (7) IIRC, we use something like that at work but for SVN. The plugin links a JIRA ticket to commits if the commit message includes the string [JIRA-ID]. There is also Altassian FishEye. Gary On Mon, May 15, 2017 at 9:34 AM, Gary Gregory

Re: [Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

On Mon, May 15, 2017 at 10:43 AM, Gary Gregory wrote: > Altassian has a plugin to handle (7) IIRC, we use something like that at > work but for SVN. The plugin links a JIRA ticket to commits if the commit > message includes the string [JIRA-ID]. There is also Altassian

Re: Fwd: [Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Am 2017-05-15 um 18:34 schrieb Gary Gregory: Hi, Thank you for kicking off this thread. I do not think "/" is good enough. At least when I tried it, EGit would not let me create a branch in a branch which makes sense. Which is what I used dev/4.4.x/HTTPCORE-466 in the HttpCore Git repo.

Re: Git policies and practices

I wonder of all the branches that are effectively temporary should be in a "temp/" root to make it obvious this is short term like my dev/4.4.x/HTTPCORE-466? Not great, but maybe less confusing? Gary On Mon, May 15, 2017 at 9:34 AM, Michael Osipov wrote: > Folks, > > I

Re: Git policies and practices

Folks, I have updated the link based on the input and put it onto the wiki: https://wiki.apache.org/HttpComponents/GitGuidelines Here is verbatim copy: = Typical Issue Workflow = 1. Branch off master ({{{git checkout -b / master}}}) where {{{}}} is the branch you are going to apply the fix,

Fwd: [Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Hi, Thank you for kicking off this thread. I do not think "/" is good enough. At least when I tried it, EGit would not let me create a branch in a branch which makes sense. Which is what I used dev/4.4.x/HTTPCORE-466 in the HttpCore Git repo. Gary -- Forwarded message --

Re: One Git repo per major version

Hi Oleg On Mon, May 15, 2017 at 11:06 AM, Oleg Kalnichevski wrote: > On Mon, 2017-05-15 at 10:09 +0200, Julian Sedding wrote: >> I am in favour of using a single repository and branches (with a >> clean >> convention). Having a repo per version IMHO sends the wrong message, >>

[Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" for change notification. The "GitGuidelines" page has been changed by MichaelOsipov: https://wiki.apache.org/HttpComponents/GitGuidelines?action=diff=4=5 1. Never rewrite (rebase) history on

[Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" for change notification. The "GitGuidelines" page has been changed by MichaelOsipov: https://wiki.apache.org/HttpComponents/GitGuidelines?action=diff=3=4 Comment: Update points ## page was renamed

[Httpcomponents Wiki] Update of "GitGuidelines" by MichaelOsipov

Dear wiki user, You have subscribed to a wiki page "Httpcomponents Wiki" for change notification. The page "GitGuidelines" has been renamed from "GitPoliciesAndPractices" by MichaelOsipov: https://wiki.apache.org/HttpComponents/GitGuidelines Comment: Rename idea on the dev mailing list

Re: Do not commit to HttpCore SVN!

On Mon, 2017-05-15 at 17:04 +0200, Michael Osipov wrote: > Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski: > > On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote: > > > > > > > > ... > I actually did:  > https://mail-archives.apache.org/mod_mbox/hc-dev/201705.mbox/%3C01066 >

Re: Do not commit to HttpCore SVN!

On Mon, May 15, 2017 at 8:04 AM, Michael Osipov wrote: > Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski: > >> On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote: >> >>> >> ... >> >> >> Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski: >>> What benefit do you have

Re: Do not commit to HttpCore SVN!

Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski: On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote: ... Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski: What benefit do you have if it is hard to follow the code paths? How much is "good" code worth if you don't have proper

[Httpcomponents Wiki] Update of "GitPoliciesAndPractices" by MichaelOsipov

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" for change notification. The "GitPoliciesAndPractices" page has been changed by MichaelOsipov: https://wiki.apache.org/HttpComponents/GitPoliciesAndPractices Comment: Prelimary Git rules New page:

Re: Do not commit to HttpCore SVN!

On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote: > > ... > Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski: > What benefit do you have if it is hard to follow the code paths? How  > much is "good" code worth if you don't have proper documentation? > Even  > if you have to constantly

Re: Do not commit to HttpCore SVN!

Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski: On Mon, 2017-05-15 at 15:18 +0200, Michael Osipov wrote: ... Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski: I have _no_ intention of policing other committers. It is emotionally cheaper for me to take time to clean things up and than

Re: Do not commit to HttpCore SVN!

On Mon, 2017-05-15 at 15:18 +0200, Michael Osipov wrote: > > ... > Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski: > > I have _no_ intention of policing other committers. It is > > emotionally > > cheaper for me to take time to clean things up and than to hold all > > those conversations

Re: Do not commit to HttpCore SVN!

Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski: On Mon, 2017-05-15 at 14:58 +0200, Michael Osipov wrote: Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski: On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote: Force pushing is considered a bad practice in Git for good reasons, thus

Re: Do not commit to HttpCore SVN!

On Mon, 2017-05-15 at 14:58 +0200, Michael Osipov wrote: > Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski: > > On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote: > > > Force pushing is considered a bad practice in Git for good > > > reasons, > > > thus rewriting history of published

Re: Do not commit to HttpCore SVN!

Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski: On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote: Force pushing is considered a bad practice in Git for good reasons, thus rewriting history of published branches is IMHO a no-go. It makes everybody's life harder (and developers less

Re: [ANNOUNCEMENT] HttpComponents Client 5.0 alpha2 released

On 12/05/2017 21:38 +0200, Oleg Kalnichevski wrote: > You are compiling the source with Java 1.8, are you not? HttpClient 5.0 > still requires Java 1.7, which is more lenient about Javadoc content. > > Oleg Yes I do. Filipp -

Re: Do not commit to HttpCore SVN!

On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote: > Force pushing is considered a bad practice in Git for good reasons, > thus rewriting history of published branches is IMHO a no-go. It > makes > everybody's life harder (and developers less experienced with Git may > not be able to

Re: Do not commit to HttpCore SVN!

Am 2017-05-15 um 11:54 schrieb Julian Sedding: Force pushing is considered a bad practice in Git for good reasons, thus rewriting history of published branches is IMHO a no-go. It makes everybody's life harder (and developers less experienced with Git may not be able to integrate the rewritten

Re: Do not commit to HttpCore SVN!

Force pushing is considered a bad practice in Git for good reasons, thus rewriting history of published branches is IMHO a no-go. It makes everybody's life harder (and developers less experienced with Git may not be able to integrate the rewritten history at all). Don't get me wrong. I do a lot

[jira] [Commented] (HTTPCORE-466) Round out the SslContextBuilder by adding missing APIs

[ https://issues.apache.org/jira/browse/HTTPCORE-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16010201#comment-16010201 ] Oleg Kalnichevski commented on HTTPCORE-466: Sure. Fair enough. Would you like me to merge

Re: One Git repo per major version

On Mon, 2017-05-15 at 10:09 +0200, Julian Sedding wrote: > I am in favour of using a single repository and branches (with a > clean > convention). Having a repo per version IMHO sends the wrong message, > namely that the new version is completely different. > Hi Julian I believe this idea is

Re: One Git repo per major version

I am in favour of using a single repository and branches (with a clean convention). Having a repo per version IMHO sends the wrong message, namely that the new version is completely different. Again IMHO, we should strive to improve our backwards compatibility with version 6.x (with regard to