Re: HC 5.0 scope and design decisions

[Julian Sedding]

Hi all

I am not familiar with log4j2, but have used slf4j extensively over
the last years.

As I understand log4j2 clearly separates its API from the
implementation. If this is true, are there any major benefits to using
the log4j2 API over the slf4j API?

If this is not the case, and the benefits of log4j2 are predominantly
in the implementation, then it may be sensible to code against the
slf4j API and leave the choice of the implementation to the
deployment. I.e. it would be possible to use log4j2 as the logging
implementation via its slf4j binding[0].

I am sure others, especially Gary, can provide more qualified opinions here.

Regards
Julian

[0] https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html


On Thu, Sep 29, 2016 at 10:00 PM, Oleg Kalnichevski  wrote:
> On Thu, 2016-09-29 at 09:27 +0530, Asankha C. Perera wrote:
>> Hi Oleg
>
> ...
>
>> > Should be remain faithful to Commons Logging or shall we finally migrate
>> > to SLF4J?
>> I agree with Gary that Log4J2 is better than SLF4J too. Since we also
>> have Gary's experience and support to move to it, I think that maybe the
>> best option.
>>
>> regards
>> asankha
>>
>
> Gary, Asankha
>
> Being a happy user of Log4J2 myself I would be very much in favor of
> using it directly. However we ought not impose a particular choice of
> the logging toolkit upon all our users. We should be using a logging
> bridge. This essentially leaves with two options: Commons Logging or
> SLF4J, both of which can use different backends including Log4J2.
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Collaborate implementing HTTP 2.0 support - HTTPCORE-432

[Julian Sedding]

It may be worthwhile to check out WireMock[0]. It allows setting up a
lightweight mock server designed for unit testing.

Regards
Julian

[0] http://wiremock.org


On Tuesday, November 22, 2016, Gary Gregory > wrote:

> You can also see if Travis CI and AppVeyer provide HTTP servers in their
> containers.
>
> Gary
>
> On Mon, Nov 21, 2016 at 1:58 PM, Francisco Carriedo Scher <
> fcarrie...@gmail.com> wrote:
>
> > I will have a look to it to get some insight and consider pros/cons.
> >
> > As I see it, automating tests against the most popular web servers would
> > be something nice if there is a relatively clean way of doing it.
> >
> > 2016-11-21 13:17 GMT-05:00 Gary Gregory :
> >
> >> The only way to do that is to embed a server in the test or have the
> test
> >> manage the life cycle of the external server. I've done that with
> Commons
> >> VFS tests, so it's doable.
> >>
> >> Gary
> >>
> >> On Nov 20, 2016 7:35 PM, "Francisco Carriedo Scher" <
> fcarrie...@gmail.com>
> >> wrote:
> >>
> >>> After having a look to the source code and the RFC, I would like to
> >>> clarify
> >>> a couple of things about the testing against popular web-servers.
> >>>
> >>> My first idea was to see if I could take some unit tests making
> requests
> >>> to
> >>> test servers as basis and generating new test classes pointing them
> >>> instead
> >>> to real running web-servers. However, after seeing the unit tests, my
> >>> impression is that perhaps this might not be the best approach or at
> >>> least
> >>> complete/realistic enough.
> >>>
> >>> The intention of this testing is to test the library from a client
> >>> perspective (as a client of the library I mean) in more real-world
> >>> scenarios, not necessarily adding additional unit tests to the existing
> >>> ones, right?
> >>>
> >>> Aside, should an issue in Jira be open for this in order to log and
> >>> document versions and keep the worklog?
> >>>
> >>> Thanks,
> >>>
> >>> Francisco
> >>>
> >>>
> >>> 2016-10-31 19:12 GMT+01:00 Francisco Carriedo Scher <
> >>> fcarrie...@gmail.com>:
> >>>
> >>> > Yes, I find moving to Log4J2 the correct choice too, so leaving Gary
> >>> work
> >>> > on the migration without conflict.
> >>> >
> >>> > I will move then forward testing against popular HTTP/2 enabled
> >>> servers.
> >>> >
> >>> >
> >>> > 2016-10-31 14:02 GMT-04:00 Oleg Kalnichevski :
> >>> >
> >>> >> On Mon, 2016-10-31 at 05:46 +0100, Francisco Carriedo Scher wrote:
> >>> >> > Hello,
> >>> >> >
> >>> >> >
> >>> >> > Don't know if migrating to Log4J2
> >>> >> > (https://issues.apache.org/jira/browse/HTTPCORE-436) would
> override
> >>> >> > the task I was working in (enabling debug logging on integration
> >>> >> > tests). Anyway, as I don't know how long migrating might take and
> >>> the
> >>> >> > work was already done for httpcore5 module I have committed it to
> my
> >>> >> > fork
> >>> >> > (https://github.com/fcarriedos/httpcore/commit/46ba8b0c408cf
> >>> >> b67d0ed6395c675b8bd2f6fa131). If you consider it correct and want me
> >>> to
> >>> >> extend it to the other modules, just say it.
> >>> >> >
> >>> >>
> >>> >> Francisco
> >>> >>
> >>> >> This will certainly conflict with Gary's changes. I had no idea you
> >>> were
> >>> >> going to introduce Log4j as a dependency. What you have done looks
> >>> >> perfectly fine to me but going forward we should be using Log4j2
> given
> >>> >> that it provides an abstract logging API with an option of using
> >>> >> different logging back-ends.
> >>> >>
> >>> >> >
> >>> >> > Question: I determined which packages to enable logging for with
> the
> >>> >> > shell command below (output attached). To me this should find any
> >>> >> > class needing to yield debug log lines. Could somebody comment on
> >>> >> > this? (Correct, incorrect, suggestions?). Thanks!
> >>> >> > $ httpcore/httpcore5$ reset && egrep -Ri "log" ./* | grep java |
> >>> grep
> >>> >> debug
> >>> >>
> >>> >> Looks correct to me.
> >>> >>
> >>> >> > DEADLOCK: when I completed this a month ago, enabling debug
> logging
> >>> >> > resulted in a dead-lock in class "TestSyncHttp.java". This test
> >>> class
> >>> >> > is not present anymore and the deadlock does not appear now, but I
> >>> >> > don't know if this could be another good reason to work on
> updating
> >>> >> > the logging framework (HTTPCORE-436), as I dug a bit and looked
> >>> like a
> >>> >> > known issue for Log4J 1.2. I can reproduce the deadlock and
> provide
> >>> >> > more detail if needed.
> >>> >> >
> >>> >>
> >>> >> More reason to move to Log4j2.
> >>> >>
> >>> >> > Meanwhile I will have a look to testing the HTTP/2 transport with
> >>> >> > popular web servers as you suggested. Please confirm if this is
> >>> still
> >>> >> > pending or somebody already is taking care of it.
> >>> >> >
> >>> >>
> >>> >> I confirm. This is still by far more important than anything 

Re: One Git repo per major version

[Julian Sedding]

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 5.x). I even believe that commonly
used APIs in 5.x would be mostly backwards compatible with 4.x if the
Java packages had not been renamed. Please feel free to correct me if
that assumption is wrong.

Regards
Julian



On Wed, May 10, 2017 at 9:44 PM, Michael Osipov  wrote:
> Folks,
>
> since there is still some disagreement on how an issue should be applied to
> 4.4.x and 5.0.x, I'd like to propose the following two ideas:
>
> Have one repo per major version and all pain will end:
>
> httpcomponents-core-4
> httpcomponents-client-4
> httpcomponents-core-5
> httpcomponents-client-5
>
> Maven and Tomcat have this too.
>
> Alternatively, we can have the following layout per httpcomponents-core and
> httpcomponents-client
>
> /
> |-- 4.4.x
> | master // this is 5.x
>
> Issue branches:
>
> 4.4.x/HTTPCORE-XXX
> 5.x/HTTPCORE-XXX
>
> Yes, this works very well with Git.
>
> I am in favor of the first proposal.
>
> Backporting from 5.x to 4.4.x is a matter of a Git remote and merge -- done.
>
> What do you think?
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Do not commit to HttpCore SVN!

[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 history at all).

Don't get me wrong. I do a lot of rebasing locally because I
appreciate a commit history that tells a story (i.e. commits should be
intentional, logical units, not accidental bits of work).

Could we perhaps achieve a pretty history by enforcing a
review-then-commit workflow? That way we can have temporary feature
branches (which may be deleted or force pushed in my book), work out
the history and only merge to master (or the respective release
branch) when we're happy with the change and the history.

Regards
Julian


On Thu, May 11, 2017 at 9:23 AM, Oleg Kalnichevski  wrote:
> On Thu, 2017-05-11 at 00:00 +0200, Michael Osipov wrote:
>> Am 2017-05-10 um 23:48 schrieb Oleg Kalnichevski:
>> > On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
>> >
>> >
>
> ...
>
>> > I am not sure I understand what you mean by git apply.
>> >
>> > Can we go back to what appears to be the only sticking point here?
>> >
>> > It seems pretty clear that major release branches do not need to be
>> > in
>> > different repos. Local clones per major release are perfectly
>> > sufficient.
>> >
>> > The question is whether or not people can live with HEADs of
>> > release
>> > branches being volatile for a short period of time (not more than a
>> > few
>> > days) until every active committer gets used to using dev branches
>> > for
>> > building change sets?
>>
>> To be more precise: do you want to do this only once or before every
>> release?
>>
>
> I want to be able to do it on a case by case basis. Like the one we
> just had.
>
> Oleg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: One Git repo per major version

[Julian Sedding]

Hi Oleg

On Mon, May 15, 2017 at 11:06 AM, Oleg Kalnichevski <ol...@apache.org> 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,
>> namely that the new version is completely different.
>>
>
> Hi Julian
>
> I believe this idea is off the table.
>
>
>> Again IMHO, we should strive to improve our backwards compatibility
>> with version 6.x (with regard to 5.x). I even believe that commonly
>> used APIs in 5.x would be mostly backwards compatible with 4.x if the
>> Java packages had not been renamed. Please feel free to correct me if
>> that assumption is wrong.
>>
>
> As far as package names are concerned some while ago we agreed to use
> the same approach as Commons and use distinct packages for major
> releases in order to make them co-locatable.

Thanks for this bit of information. I believe it's unfortunate, but of
course it's a trade-off and both sides have valid arguments. So let's
leave it at that.

Regards
Julian

>
> Oleg
>
>
>> Regards
>> Julian
>>
>>
>>
>> On Wed, May 10, 2017 at 9:44 PM, Michael Osipov <micha...@apache.org>
>> wrote:
>> > Folks,
>> >
>> > since there is still some disagreement on how an issue should be
>> > applied to
>> > 4.4.x and 5.0.x, I'd like to propose the following two ideas:
>> >
>> > Have one repo per major version and all pain will end:
>> >
>> > httpcomponents-core-4
>> > httpcomponents-client-4
>> > httpcomponents-core-5
>> > httpcomponents-client-5
>> >
>> > Maven and Tomcat have this too.
>> >
>> > Alternatively, we can have the following layout per httpcomponents-
>> > core and
>> > httpcomponents-client
>> >
>> > /
>> > > -- 4.4.x
>> > > master // this is 5.x
>> >
>> > Issue branches:
>> >
>> > 4.4.x/HTTPCORE-XXX
>> > 5.x/HTTPCORE-XXX
>> >
>> > Yes, this works very well with Git.
>> >
>> > I am in favor of the first proposal.
>> >
>> > Backporting from 5.x to 4.4.x is a matter of a Git remote and merge
>> > -- done.
>> >
>> > What do you think?
>> >
>> > Michael
>> >
>> > -
>> > 
>> > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>> > For additional commands, e-mail: dev-h...@hc.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>> For additional commands, e-mail: dev-h...@hc.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Julian Sedding]

Hi Oleg and Michael

I understand your frustration with a messy commit log.

Personally I strive to give context so that the commit can more easily
be understood. Normally that includes a JIRA ID and the title. There
are cases where I prefer to have several commits for one JIRA, but
only if the separate commits help understand the changes AND the state
after each commit is sane (i.e. build and tests work, system is
functional).

So far I don't understand why the commit log is required to create
release notes. I would expect this information to be in JIRA. But
maybe that assumption is wrong.

Still, I am reluctant to make rebasing/squashing of public history the
de-facto default.

The Git rebase documentation's section about recovering from upstream
rebase[0] starts with the words:

"Rebasing (or any other form of rewriting) a branch that others have
based work on is a bad idea: anyone downstream of it is forced to
manually fix their history."

Likewise the Git book talks about the perils of rebasing[1] and gives
the following advice before giving examples of problematic scenarios :

"Do not rebase commits that exist outside your repository. If you
follow that guideline, you’ll be fine. If you don’t, people will hate
you, and you’ll be scorned by friends and family."

Bear in mind that you are most likely more skilled in using Git than
the average contributor. If someone is preparing a patch to contribute
and the next thing their Git repo doesn't work anymore (and they don't
know how to fix it), that person may well turn their back to the
httpcomponents project before even getting in touch.

Just my 2 cts. YMMV.

Regards
Julian

[0] https://git-scm.com/docs/git-rebase.html#_recovering_from_upstream_rebase
[1] https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_peril


On Tue, May 16, 2017 at 10:30 AM, Oleg Kalnichevski  wrote:
> On Tue, 2017-05-16 at 10:17 +0200, Michael Osipov wrote:
>> Am 2017-05-16 um 09:22 schrieb Oleg Kalnichevski:
>> > So, I woke up this morning, took a look at my mail box and found
>> > two
>> > wonderful commit messages on top of the 4.4.x release branch saying
>> > 'oh, forgot this' and 'ah, forgot that' immediately after a dev
>> > branch
>> > merge.
>> >
>> > Shit like that will happen over and over again because people tend
>> > to
>> > forget things and tend to make mistakes all the time.
>>
>> We were talking against the wall. It is pretty much useless :(
>> History
>> repeats. There are even forced updates...that's so disappointing!
>>
>
> Forced update is my atrocity. I squashed those two commits.
>
>> > I will be vehemently against (to a point of using my -1 as a veto
>> > if
>> > needed) any policy that stops RMs from squashing such commits
>> > within a
>> > defined period of time.
>>
>> When I see this history, I'd always give the RM the right/vote to
>> clean
>> up the crap -- but again, this is a waste of your precious time.
>> Really
>> sad about it. There is a huge lack of selforganization. I tend to do
>> double-reviews these days -- even solving an issue takes three days
>> longer. So what?
>>
>
> I am sure it will get better. For now we just need to be pragmatic.
>
> Oleg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Git policies and practices / of tendency for good intentions to turn into s..t

[Julian Sedding]

Hi Michael

On Wed, May 17, 2017 at 10:57 AM, Michael Osipov <micha...@apache.org> wrote:
> Hi Julian,
>
> Am 2017-05-17 um 09:30 schrieb Julian Sedding:
>>
>> Hi Oleg and Michael
>>
>> I understand your frustration with a messy commit log.
>>
>> Personally I strive to give context so that the commit can more easily
>> be understood. Normally that includes a JIRA ID and the title. There
>> are cases where I prefer to have several commits for one JIRA, but
>> only if the separate commits help understand the changes AND the state
>> after each commit is sane (i.e. build and tests work, system is
>> functional).
>
>
> That's perfectly fine and correct. With several commits for one issue we
> mean that followup commits say: "forgot that", or "um this too".
>
>> So far I don't understand why the commit log is required to create
>> release notes. I would expect this information to be in JIRA. But
>> maybe that assumption is wrong.
>
>
> I absolutely agree, I see no reason to maintain separate release notes. We
> have JIRA. Everything has to be an issue, unless you fix a typo or so.
>
>> Still, I am reluctant to make rebasing/squashing of public history the
>> de-facto default.
>>
>> The Git rebase documentation's section about recovering from upstream
>> rebase[0] starts with the words:
>>
>> "Rebasing (or any other form of rewriting) a branch that others have
>> based work on is a bad idea: anyone downstream of it is forced to
>> manually fix their history."
>>
>> Likewise the Git book talks about the perils of rebasing[1] and gives
>> the following advice before giving examples of problematic scenarios :
>>
>> "Do not rebase commits that exist outside your repository. If you
>> follow that guideline, you’ll be fine. If you don’t, people will hate
>> you, and you’ll be scorned by friends and family."
>
>
> Absolutely.
>
>> Bear in mind that you are most likely more skilled in using Git than
>> the average contributor. If someone is preparing a patch to contribute
>> and the next thing their Git repo doesn't work anymore (and they don't
>> know how to fix it), that person may well turn their back to the
>> httpcomponents project before even getting in touch.
>
>
> This is a constant problem when reviewing PRs for the Maven project.
> 1) People are using Git like Subversion and never used squash before
> 2) They are completely swamped when I ask them to rebase their PR on top of
> master. A lot of them can't do.
> I don't want to image what will happen if they encouter a rewritten upstream
> branch when pulling...
>

Yes, I think we need to accept this and encourage contributors to
improve their skills, if necessary. We should provide some guidance,
and if that does not help, we can always pull the branch underlying a
PR into a local repo and refactor/rebase *before* it enters the
httpcomponents repo.

Arguably harder is to get committers to make clean commits. However,
IMHO git makes this easier, exactly because you can commit locally and
rebase/squash local changes. Therefore I have hope that the situation
improves after everyone transitions to git and improves their git
skills. Again, we may need to provide some guidance, which you
(Michael) have already been doing with the Git guidelines.

Regards
Julian

> Michael
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HttpCore / HttpClient fully migrated to Git

[Julian Sedding]

Thanks Oleg for taking care of the migration to Git!

I have no strong opinion regarding the repos, just a slight preference
to keep it simple: httpcomponents-project.

Regards
Julian


On Wed, May 17, 2017 at 3:53 PM, Oleg Kalnichevski  wrote:
> Folks
>
> HttpCore / HttpClient have been fully migrated to Git, GitHub
> replication and all.
>
> Happy hacking, pushing and rebasing.
>
> We now need to decide what kind of other repositories we need
>
> One option if I remember correctly was to have separate repos for style
> check, parent and website
>
> httpcomponents-website
> httpcomponents-parent
> httpcomponents-stylecheck
> httpcomponents-
>
> I personally would be fine with just two repos
>
> httpcomponents-website
> httpcomponents-project
>
> but I will not insist.
>
> So, what option shall I go for?
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Git policies and practices

[Julian Sedding]

Hi Oleg

As I explained in the thread branched from this one, I fear that
rewriting public history will irritate/alienate potential contributors
as well as existing committers.

In my opinion deterring contributors is a hefty price to pay in order
to satisfy your desire for an immaculate public history.

As I understand it, you "need" the clean public history in order to
create the release notes. Is that correct?

I suggested to base the release notes on JIRA issues instead. Is this
not possible? If yes, why?

We can already fully control if a PR is merged or not, so we are only
talking about committers spoiling the history. I believe we should be
able to encourage and teach a relatively small group of people to
improve their habits. Your threat of a veto suggests that you are more
pessimistic about this, which makes me sad, especially should you be
right.

My strong preference is to trust the circle of committers instead of
rewriting public history.

Regards
Julian



On Fri, May 19, 2017 at 2:59 PM, Oleg Kalnichevski  wrote:
> On Fri, 2017-05-19 at 13:19 +0200, Michael Osipov wrote:
>> Since I haven't received anymore comments on the guidelines, I'll
>> close
>> the questioning and call a vote for commmitters and PMC members.
>>
>> Michael
>>
>
> Michael
>
> I just want to tell you upfront I will vote -1 on the proposal as long
> as it has the clause about never rewriting release branches.
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Git policies and practices

[Julian Sedding]

On Fri, May 19, 2017 at 3:30 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2017-05-19 at 15:14 +0200, Julian Sedding wrote:
>> Hi Oleg
>>
>> As I explained in the thread branched from this one, I fear that
>> rewriting public history will irritate/alienate potential
>> contributors
>> as well as existing committers.
>>
>>
>> In my opinion deterring contributors is a hefty price to pay in order
>> to satisfy your desire for an immaculate public history.
>>
>
> ah, please, let us not start over again. Rebasing is a problem only for

What exactly are we starting over? You have not replied to one single
question or statement of mine. I am trying to have a constructive
discussion.

> projects that have long standing forks maintained by external parties,
> like Linux kernel project. We do _not_ have external forks maintained
> externally as far as I know. The rest is just subjective speculations.
>

I never said anything about forks. Every *clone* of the repository is
affected, causing any developer (committer or not) with a local clone
problems. I argue that this will deter possible contributions.

>
>> As I understand it, you "need" the clean public history in order to
>> create the release notes. Is that correct?
>>
>> I suggested to base the release notes on JIRA issues instead. Is this
>> not possible? If yes, why?
>>
>
> Because the commit log is the _only_ _authoritative_ representation of
> the project state.
>
> I do pretty much all the heaving lifting for the project. Please do not
> make me raise a bloody JIRA for every bloody commit. You do not get
> enough of raising tickets at work? I do.

If an issue is important enough to appear in the release notes, I
think a JIRA ticket is warranted.

If an issue is so insignificant that a JIRA seems like overhead, then
it does not need to appear in the release notes.

>
> The problem immediately goes away as soon as people start using release
> branches responsibly.

That's why I argue we should rather educate the projects committers
than institutionalize a documented bad practice.

>
> Oleg

I would still be interested to get a reply to the questions and
suggestions I made in order to find a compromise that everyone can
live with.

Regards
Julian

>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Limiting the blast radius of connection leaks

[Julian Sedding]

Hi

I don't know if Java's "reachability" of responses would be a good
indicator for when a connection has erroneously not been returned to a
pool. If that is the case (and the stated memory leak makes me think
it might be), then the below information may be helpful.

I'll share some (positive) experiences from the Apache Sling project
with an approach that may work here as well. Sling is a Web-Framework
built on top of JCR (Java Content Repository, think of it as a
hierarchical database). For each request, a ResourceResolver is
created based on user credentials (often anonymous). The
ResourceResolver (RR) needs to be closed at the end of the request. So
far the framework can manage the lifecycle of the RR - no problem.
However, it is also possible to obtain a RR in components that
implement some backend logic, e.g. a scheduled task performing some
maintenance or reporting. In these cases the responsibility for
closing the RR is with the programmer implementing that piece of
backend logic. Of course that is often forgotten and leads to a memory
leak (leaked RR instances).

Solving this issue with a finalize method would work, but finalize is
known to require synchronization and to be rather slow. Instead we
implemented a mechanism to close unclosed RR instances using Java's
java.lang.ref.ReferenceQueue and WeakReference, see
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/30f7d91c6c99dc674fe361060aaa90f6e0252a6a/src/main/java/org/apache/sling/resourceresolver/impl/CommonResourceResolverFactoryImpl.java#L525

The trick is to encapsulate all required state in one object and then
create another object that references the state, but has no (relevant)
state of its own, a bit like a facade. When the facade gets GC'ed you
get a WeakReference referencing the state object enqueued in the
ReferenceQueue and all resources can be closed. In Sling we also give
the possibility to log the "opening stacktrace" when an RR is closed
by this fallback mechanism. This can help identify places in the
source code where RRs aren't correctly closed.

Hope this may help.

Regards
Julian

On Mon, Aug 3, 2020 at 7:39 PM Gary Gregory  wrote:
>
> Hi Carter,
>
> I don't have a super strong feeling for this either. I just would like us
> to try and reuse a library before reinventing the wheel, but my time is
> limited, like everyone else.
>
> Gary
>
> On Mon, Aug 3, 2020, 13:19 Carter Kozak  wrote:
>
> > Hi Gary,
> >
> > That sounds reasonable, however there are some subtle distinctions
> > between general purpose object pools and those used for http
> > connections, perhaps the most obvious of which is http/2 multiplexed
> > connections. It's certainly possible that it could work, but I imagine it
> > could become a large project and may result in something very
> > specific to http clients. Pools used by blocking and asynchronous
> > clients may also differ substantially, so I'm not sure how general this
> > implementation could be.
> >
> > I'd be happy to help in any way I can if folks more familiar than myself
> > with the current hc pool implementations are supportive of your proposal,
> > but I'm worried that it may become a blocker that prevents incremental
> > improvements.
> >
> > In conclusion, I don't feel comfortable taking a stance on this and I trust
> > the team to make the right decision.
> >
> > -ck
> >
> > On Fri, Jul 31, 2020, at 17:38, Gary Gregory wrote:
> > > What I would prefer we do is not reinvent yet another pooling feature,
> > all
> > > its potential bugs and added maintenance load when that wheel's been
> > > invented over and over. For me personally, I would prefer that this
> > project
> > > adopt a FOSS pooling library and improve _it_ if that were needed,
> > thereby
> > > improving the whole ecosystem.
> > >
> > > Gary
> > >
> > > On Fri, Jul 31, 2020, 16:22 Carter Kozak  wrote:
> > >
> > > > On Fri, Jul 31, 2020, at 14:31, Gary Gregory wrote:
> > > > > On Fri, Jul 31, 2020 at 12:45 PM Oleg Kalnichevski  > >
> > > > wrote:
> > > > >
> > > > > > On Thu, 2020-07-30 at 13:28 -0400, Carter Kozak wrote:
> > > > > > > Hello Friends,
> > > > > > >
> > > > > > > I recently had a service crash due to an out of memory error as
> > the
> > > > > > > result of a response leak. While this is caused by code that uses
> > > > > > > closeable resources incorrectly, and that code should be fixed,
> > I'd
> > > > > > > like to discuss some ideas which could avoid catastrophic
> > failure in
> > > > > > > this scenario.
> > > > > > >
> > > > > > > A little background on my environment: I maintain an RPC library
> > > > > > > which wraps an hc5 client. There's no limit set on the hc5
> > connection
> > > > > > > pool (Integer.MAX_VALUE), and resource use is bounded using a
> > > > > > > variation of additive-increase/multiplicative-decrease limiters
> > to
> > > > > > > scale based on load. Some endpoints are capable of returning a
> > raw
> > > > > > > binary stream, this introduces some risk of 

Re: Time to say goodbye to Clirr; Re: Upgrade 5.1 branches to Java 1.8

[Julian Sedding]

I'm not familiar with Clirr, but I think the
"bnd-baseline-maven-plugin" does something similar. It's geared
towards OSGi bundles, but may work with regular jars as well. It
compares two OSGi bundles (or jar files) and reports API changes
classified according to semantic versioning rules. I'm using bnd's
baselining functionality (via this or other plugins) on a regular
basis and it is mostly trouble free both to run and to setup.

I know that the HttpComponents project isn't very interested in OSGi.
But it may be worthwhile trying if this fits the bill. Maybe adding
minimal OSGi metadata by default with versioned package exports could
be beneficial in order to formally describe API compatibility.

Regards
Julian

[0] https://github.com/bndtools/bnd/tree/master/maven/bnd-baseline-maven-plugin

On Sat, Dec 5, 2020 at 2:56 PM Gary Gregory  wrote:
>
> I've been working with JApiCmp for a while now, and it seems fine, it
> works, it's maintained and highly configurable.
>
> I only know that revapi is in Log4j because I see it fly by during local
> builds but I've not had to actually deal with it.
>
> So I can't contrast and compare. If I had to pick myself I'd just go with
> what I know now and move on from there.
>
> Gary
>
> On Sat, Dec 5, 2020, 08:35 Oleg Kalnichevski  wrote:
>
> > On Sat, 2020-12-05 at 08:10 -0500, Gary Gregory wrote:
> > > Over at Aapche Commons, we switched to JApiCmp, while at Log4j, we
> > > switched
> > > to revapi.
> > >
> >
> > Which one would you recommend?
>
>
> > Oleg
> >
> > > Gary
> > >
> > > On Sat, Dec 5, 2020, 07:51 Oleg Kalnichevski 
> > > wrote:
> > >
> > > > ...
> > > >
> > > > > Hi Michael
> > > > >
> > > > > That would mean somewhat more work for me but what you are saying
> > > > > makes
> > > > > sense. I will back out protocol upgrade APIs from master and will
> > > > > move
> > > > > them along with Java 8 changes to 5.2.x branch.
> > > > >
> > > > > Oleg
> > > > >
> > > >
> > > > One more thing. I just discovered that Clirr cannot handle certain
> > > > Java
> > > > 8 features correctly, most importantly default methods in
> > > > interfaces. I
> > > > am looking into ways of either fixing Clirr or more likely finding
> > > > a
> > > > better alternative.
> > > >
> > > > Oleg
> > > >
> > > >
> > > >
> > > > -
> > > > 
> > > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > > > For additional commands, e-mail: dev-h...@hc.apache.org
> > > >
> > > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > For additional commands, e-mail: dev-h...@hc.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1811) Security : Authorization header should not be printed in debug log

[Julian Sedding (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848608#comment-15848608
 ] 

Julian Sedding commented on HTTPCLIENT-1811:


I'm against swallowing the header value, as that can be highly misleading when 
debugging an issue. If we keep the log but only obfuscate the value (and 
indicate that it is obfuscated!), that would be fine for me. Keeping the 
obfuscated value stable, so it can be grepped etc would also be helpful. Maybe 
shortening the value or hashing it would work?

> Security : Authorization header should not be printed in  debug log
> ---
>
> Key: HTTPCLIENT-1811
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1811
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Reporter: Sujitha Chinnathambi
> Attachments: httpclient.patch
>
>
> Current behaviour : When https call is made with basic authentication  with  
> debug mode, authorization information which is transfered part of 
> 'Authorization' header is getting printed in log in below artifact
>   org.apache.httpcomponents
>   httpclient
>   4.3.6
> Example : 
> org.apache.http.wire - []  >> "Authorization: Basic 
> VEVTVCBLSCAwMS9TQ0hVTFVORzpzY2h1bHVuZw==[\r][\n]"
> org.apache.http.headers - [] >> Authorization: Basic 
> VEVTVCBLSCAwMS9TQ0hVTFVORzpzY2h1bHVuZw==
> Expected behaiour: 
> Though log level is debug, authorization information should not be  printed 
> in log.
> Attached httpclient.patch as proposal.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1813) [OSGi] ServiceRegistration properties of OSGiProxyConfiguration not updated

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1813:
--

 Summary: [OSGi] ServiceRegistration properties of 
OSGiProxyConfiguration not updated
 Key: HTTPCLIENT-1813
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1813
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.3
Reporter: Julian Sedding
Assignee: Julian Sedding
Priority: Minor


The ServiceRegistration properties of the OSGiProxyConfiguration service are 
not updated on configuration changes. This has no functional impact, as the 
OSGiProxyConfiguration instance is updated, however reporting tools such as the 
Felix webconsole may indicate erroneous (old) information.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1777) [OSGi] remove duplication between OSGiClientBuilderFactory and OSGiCachingClientBuilderFactory

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1777:
--

 Summary: [OSGi] remove duplication between 
OSGiClientBuilderFactory and OSGiCachingClientBuilderFactory
 Key: HTTPCLIENT-1777
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1777
 Project: HttpComponents HttpClient
  Issue Type: Improvement
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding
Assignee: Julian Sedding
Priority: Minor


It would be desirable to reduce code duplication between 
{{OSGiClientBuilderFactory}} and {{OSGiCachingClientBuilderFactory}} in order 
to reduce the impact when adding/refactoring features of the OSGi client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1777) [OSGi] remove duplication between OSGiClientBuilderFactory and OSGiCachingClientBuilderFactory

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1777.

   Resolution: Fixed
Fix Version/s: 5.0 Alpha2
   4.5.3

Fixed in {{trunk}} in [r1763260|https://svn.apache.org/r1763260].
Fixed in {{branches/4.5.x}} in [r1763267|https://svn.apache.org/r1763267].

> [OSGi] remove duplication between OSGiClientBuilderFactory and 
> OSGiCachingClientBuilderFactory
> --
>
> Key: HTTPCLIENT-1777
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1777
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
>
> It would be desirable to reduce code duplication between 
> {{OSGiClientBuilderFactory}} and {{OSGiCachingClientBuilderFactory}} in order 
> to reduce the impact when adding/refactoring features of the OSGi client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1778) [OSGi] simplify handling of ManagedService based configurations

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1778.

   Resolution: Fixed
Fix Version/s: 5.0 Alpha2
   4.5.3

Fixed in {{trunk}} in [r1763261|https://svn.apache.org/r1763261] and 
[r1763263|https://svn.apache.org/r1763263].
Fixed in {{branches/4.5.x}} in [r1763268|https://svn.apache.org/r1763268].


> [OSGi] simplify handling of ManagedService based configurations
> ---
>
> Key: HTTPCLIENT-1778
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1778
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
>
> The handling of both the {{ProxyConfiguration}}s and the 
> {{TrustedHostsConfiguration}} can be greatly simplified. Currently the 
> consumers of these objects retrieve them from the OSGi framework. Since all 
> of these objects are mutable singletons and are continually updated to 
> reflect the latest configuration, it is unnecessary to get them over and over 
> again from the framework.
> The {{ProxyConfiguration}}s can be handed down as a 
> {{List}} and the {{TrustedHostsConfiguration}} can be 
> handed down as-is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1778) [OSGi] simplify handling of ManagedService based configurations

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed HTTPCLIENT-1778.
--

> [OSGi] simplify handling of ManagedService based configurations
> ---
>
> Key: HTTPCLIENT-1778
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1778
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
>
> The handling of both the {{ProxyConfigurations}} and the 
> {{TrustedHostsConfiguration}} can be greatly simplified. Currently the 
> consumers of these objects retrieve them from the OSGi framework. Since all 
> of these objects are mutable singletons and are continually updated to 
> reflect the latest configuration, it is unnecessary to get them over and over 
> again from the framework.
> The {{ProxyConfigurations}} can be handed down as a 
> {{List}} and the {{TrustedHostsConfiguration}} can be 
> handed down as-is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1778) [OSGi] simplify handling of ManagedService based configurations

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1778:
--

 Summary: [OSGi] simplify handling of ManagedService based 
configurations
 Key: HTTPCLIENT-1778
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1778
 Project: HttpComponents HttpClient
  Issue Type: Improvement
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding
Assignee: Julian Sedding
Priority: Minor


The handling of both the {{ProxyConfiguration}}s and the 
{{TrustedHostsConfiguration}} can be greatly simplified. Currently the 
consumers of these objects retrieve them from the OSGi framework. Since all of 
these objects are mutable singletons and are continually updated to reflect the 
latest configuration, it is unnecessary to get them over and over again from 
the framework.

The {{ProxyConfiguration}}s can be handed down as a 
{{List}} and the {{TrustedHostsConfiguration}} can be 
handed down as-is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1778) [OSGi] simplify handling of ManagedService based configurations

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1778:
---
Description: 
The handling of both the {{ProxyConfigurations}} and the 
{{TrustedHostsConfiguration}} can be greatly simplified. Currently the 
consumers of these objects retrieve them from the OSGi framework. Since all of 
these objects are mutable singletons and are continually updated to reflect the 
latest configuration, it is unnecessary to get them over and over again from 
the framework.

The {{ProxyConfigurations}} can be handed down as a 
{{List}} and the {{TrustedHostsConfiguration}} can be 
handed down as-is.

  was:
The handling of both the {{ProxyConfiguration}}s and the 
{{TrustedHostsConfiguration}} can be greatly simplified. Currently the 
consumers of these objects retrieve them from the OSGi framework. Since all of 
these objects are mutable singletons and are continually updated to reflect the 
latest configuration, it is unnecessary to get them over and over again from 
the framework.

The {{ProxyConfiguration}}s can be handed down as a 
{{List}} and the {{TrustedHostsConfiguration}} can be 
handed down as-is.


> [OSGi] simplify handling of ManagedService based configurations
> ---
>
> Key: HTTPCLIENT-1778
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1778
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
>
> The handling of both the {{ProxyConfigurations}} and the 
> {{TrustedHostsConfiguration}} can be greatly simplified. Currently the 
> consumers of these objects retrieve them from the OSGi framework. Since all 
> of these objects are mutable singletons and are continually updated to 
> reflect the latest configuration, it is unnecessary to get them over and over 
> again from the framework.
> The {{ProxyConfigurations}} can be handed down as a 
> {{List}} and the {{TrustedHostsConfiguration}} can be 
> handed down as-is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1777) [OSGi] remove duplication between OSGiClientBuilderFactory and OSGiCachingClientBuilderFactory

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed HTTPCLIENT-1777.
--

> [OSGi] remove duplication between OSGiClientBuilderFactory and 
> OSGiCachingClientBuilderFactory
> --
>
> Key: HTTPCLIENT-1777
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1777
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
>
> It would be desirable to reduce code duplication between 
> {{OSGiClientBuilderFactory}} and {{OSGiCachingClientBuilderFactory}} in order 
> to reduce the impact when adding/refactoring features of the OSGi client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1782) [OSGi] List of tracked HTTPClients is mutable but not thread-safe

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed HTTPCLIENT-1782.
--

> [OSGi] List of tracked HTTPClients is mutable but not thread-safe
> -
>
> Key: HTTPCLIENT-1782
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1782
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>
> The list of tracked HTTPClients needs to be thread-safe, because the 
> {{OSGiClientBuilderFactory}} (and caching variant) may be accessed 
> concurrently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1782) [OSGi] List of tracked HTTPClients is mutable but not thread-safe

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1782.

Resolution: Fixed

Fixed in {{trunk}} in  [r1763285|https://svn.apache.org/r1763285].
Fixed in {{branches/4.5.x}} in [r1763284|https://svn.apache.org/r1763284].

> [OSGi] List of tracked HTTPClients is mutable but not thread-safe
> -
>
> Key: HTTPCLIENT-1782
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1782
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>
> The list of tracked HTTPClients needs to be thread-safe, because the 
> {{OSGiClientBuilderFactory}} (and caching variant) may be accessed 
> concurrently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1779) [OSGi] support NTLM proxy authentication

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1779.

   Resolution: Fixed
Fix Version/s: 5.0 Alpha2
   4.5.3

Fixed in {{trunk}} in [r1763275|https://svn.apache.org/r1763275] and 
[r1763278|https://svn.apache.org/r1763278].
Fixed in {{branches/4.5.x}} in [r1763279|https://svn.apache.org/r1763279].

> [OSGi] support NTLM proxy authentication
> 
>
> Key: HTTPCLIENT-1779
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1779
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
>
> Currently only BASIC authentication is possible for configured proxies. If an 
> auth-challenge results in NTLM credentials to be requested, authentication 
> fails, because the wrong credentials object is returned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1781) [OSGi] OSGiTrustedHostsConfiguration is mutable but not thread-safe

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1781:
--

 Summary: [OSGi] OSGiTrustedHostsConfiguration is mutable but not 
thread-safe
 Key: HTTPCLIENT-1781
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1781
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding


{{OSGiTrustedHostsConfiguration}} objects can be updated while being used by 
other threads.

The update of a {{OSGiTrustedHostsConfiguration}} should be atomic and the 
changes visible to other threads immediately after the update.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1782) [OSGi] List of tracked HTTPClients is mutable but not thread-safe

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1782:
--

 Summary: [OSGi] List of tracked HTTPClients is mutable but not 
thread-safe
 Key: HTTPCLIENT-1782
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1782
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding
Assignee: Julian Sedding


The list of tracked HTTPClients needs to be thread-safe, because the 
{{OSGiClientBuilderFactory}} (and caching variant) may be accessed concurrently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1779) [OSGi] support NTLM proxy authentication

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed HTTPCLIENT-1779.
--

> [OSGi] support NTLM proxy authentication
> 
>
> Key: HTTPCLIENT-1779
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1779
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
>
> Currently only BASIC authentication is possible for configured proxies. If an 
> auth-challenge results in NTLM credentials to be requested, authentication 
> fails, because the wrong credentials object is returned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1780) [OSGi] ProxyConfiguration is mutable but not thread-safe

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1780:
--

 Summary: [OSGi] ProxyConfiguration is mutable but not thread-safe
 Key: HTTPCLIENT-1780
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1780
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1
Reporter: Julian Sedding
Priority: Minor


{{ProxyConfiguration}} objects can be updated while being used by other threads.

The update of a {{ProxyConfiguration}} should be atomic and the changes visible 
to other threads immediately after the update.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1770) [OSGi] metatype for org.apache.http.proxyconfigurator missing factoryPid

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1770:
--

 Summary: [OSGi] metatype for org.apache.http.proxyconfigurator 
missing factoryPid
 Key: HTTPCLIENT-1770
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1770
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding
Priority: Minor


The metatype definition for {{org.apache.http.proxyconfigurator}} only lists 
the {{pid}} attribute on the {{Designate}} element. As it is a 
{{ManagedServiceFactory}} supporting multiple proxy configurations, the 
metatype should include a {{factoryPid}} attribute.

E.g. in the Felix webconsole's configuration screen, there are currently two 
entries, one for a singleton component configuration and one for a factory 
configuration. This is confusing for users, especially since the singleton 
configuration does not work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1771) [OSGi] improve webconsole display for org.apache.http.proxyconfigurator

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1771:
--

 Summary: [OSGi] improve webconsole display for 
org.apache.http.proxyconfigurator
 Key: HTTPCLIENT-1771
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1771
 Project: HttpComponents HttpClient
  Issue Type: Improvement
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding
Priority: Minor


Since version 4.2.6 the Felix webconsole supports "nameHints" for configuration 
factories. These allow to display some of the configuration values in the 
configuration webconsole pugin to allow easier identification of configurations.

The property {{webconsole.configurationFactory.nameHint}} should be added to 
the metatype definition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1771) [OSGi] improve webconsole display for org.apache.http.proxyconfigurator

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1771:
---
Attachment: before.png
after.png
HTTPCLIENT-1771-jsedding.patch

Attached is a patch to add the relevant metatype property.

Before
!before.png!

After
!after.png!

> [OSGi] improve webconsole display for org.apache.http.proxyconfigurator
> ---
>
> Key: HTTPCLIENT-1771
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1771
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>Priority: Minor
> Attachments: HTTPCLIENT-1771-jsedding.patch, after.png, before.png
>
>
> Since version 4.2.6 the Felix webconsole supports "nameHints" for 
> configuration factories. These allow to display some of the configuration 
> values in the configuration webconsole pugin to allow easier identification 
> of configurations.
> The property {{webconsole.configurationFactory.nameHint}} should be added to 
> the metatype definition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1770) [OSGi] metatype for org.apache.http.proxyconfigurator missing factoryPid

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1770:
---
Attachment: HTTPCLIENT-1770-jsedding.patch

Attached patch fixes the issue.

> [OSGi] metatype for org.apache.http.proxyconfigurator missing factoryPid
> 
>
> Key: HTTPCLIENT-1770
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1770
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>Priority: Minor
>  Labels: osgi
> Attachments: HTTPCLIENT-1770-jsedding.patch
>
>
> The metatype definition for {{org.apache.http.proxyconfigurator}} only lists 
> the {{pid}} attribute on the {{Designate}} element. As it is a 
> {{ManagedServiceFactory}} supporting multiple proxy configurations, the 
> metatype should include a {{factoryPid}} attribute.
> E.g. in the Felix webconsole's configuration screen, there are currently two 
> entries, one for a singleton component configuration and one for a factory 
> configuration. This is confusing for users, especially since the singleton 
> configuration does not work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1773) [OSGi] HttpProxyConfigurationActivator does not unregister HttpClientBuilderFactory

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1773:
---
Attachment: (was: HTTPCLIENT-1773-jsedding.patch)

> [OSGi] HttpProxyConfigurationActivator does not unregister 
> HttpClientBuilderFactory
> ---
>
> Key: HTTPCLIENT-1773
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1773
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>
> The {{HttpProxyConfigurationActivator}} does not unregister the   
> {{HttpClientBuilderFactory}} service when the bundle is stopped. This seems 
> to be a copy & past error, because the {{CachingHttpClientBuilderFactory}} 
> registration overrides the value of the field {{clientFactory}}, which before 
> holds the required registration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1772) [OSGi] WeakList needs to support "clear" method

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1772:
--

 Summary: [OSGi] WeakList needs to support "clear" method
 Key: HTTPCLIENT-1772
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1772
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding


The {{WeakList}} implementation introduced in HTTPCLIENT-1749 does not 
currently implement the {{close()}} method.

However, {{HttpProxyConfigurationActivator}} calls this method when the OSGi 
bundle is stopped, leading to an exception being thrown.

{noformat}
org.osgi.framework.BundleException: Activator stop error in bundle 
org.apache.httpcomponents.httpclient [122].
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2663)
at org.apache.felix.framework.Felix.updateBundle(Felix.java:2341)
at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
at 
org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:60)
at 
org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:93)
at 
org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:70)
at 
org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:123)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.UnsupportedOperationException: null
at java.util.AbstractList.remove(AbstractList.java:161)
at java.util.AbstractList$Itr.remove(AbstractList.java:374)
at java.util.AbstractList.removeRange(AbstractList.java:571)
at java.util.AbstractList.clear(AbstractList.java:234)
at 
org.apache.http.osgi.impl.HttpProxyConfigurationActivator.stop(HttpProxyConfigurationActivator.java:140)
at 
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2607)
... 7 common frames omitted
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1773) [OSGi] HttpProxyConfigurationActivator does not unregister HttpClientBuilderFactory

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1773:
---
Attachment: HTTPCLIENT-1773-jsedding.patch

Replaced the patch. I noticed I had forgotten to clear the list of 
registrations.

> [OSGi] HttpProxyConfigurationActivator does not unregister 
> HttpClientBuilderFactory
> ---
>
> Key: HTTPCLIENT-1773
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1773
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
> Attachments: HTTPCLIENT-1773-jsedding.patch
>
>
> The {{HttpProxyConfigurationActivator}} does not unregister the   
> {{HttpClientBuilderFactory}} service when the bundle is stopped. This seems 
> to be a copy & past error, because the {{CachingHttpClientBuilderFactory}} 
> registration overrides the value of the field {{clientFactory}}, which before 
> holds the required registration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1773) [OSGi] HttpProxyConfigurationActivator does not unregister HttpClientBuilderFactory

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1773:
--

 Summary: [OSGi] HttpProxyConfigurationActivator does not 
unregister HttpClientBuilderFactory
 Key: HTTPCLIENT-1773
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1773
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1, 4.5.2
Reporter: Julian Sedding


The {{HttpProxyConfigurationActivator}} does not unregister the   
{{HttpClientBuilderFactory}} service when the bundle is stopped. This seems to 
be a copy & past error, because the {{CachingHttpClientBuilderFactory}} 
registration overrides the value of the field {{clientFactory}}, which before 
holds the required registration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1773) [OSGi] HttpProxyConfigurationActivator does not unregister HttpClientBuilderFactory

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1773:
---
 Assignee: Julian Sedding
Affects Version/s: (was: 5.0 Alpha1)

> [OSGi] HttpProxyConfigurationActivator does not unregister 
> HttpClientBuilderFactory
> ---
>
> Key: HTTPCLIENT-1773
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1773
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>    Reporter: Julian Sedding
>Assignee: Julian Sedding
> Attachments: HTTPCLIENT-1773-jsedding.patch
>
>
> The {{HttpProxyConfigurationActivator}} does not unregister the   
> {{HttpClientBuilderFactory}} service when the bundle is stopped. This seems 
> to be a copy & past error, because the {{CachingHttpClientBuilderFactory}} 
> registration overrides the value of the field {{clientFactory}}, which before 
> holds the required registration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1773) [OSGi] HttpProxyConfigurationActivator does not unregister HttpClientBuilderFactory

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1773.

   Resolution: Fixed
Fix Version/s: 4.5.3

Fixed in 4.5.x [r1762930|https://svn.apache.org/r1762930].
The issue was already fixed in trunk as a side-effect of HTTPCLIENT-1752 
([r1754122|https://svn.apache.org/1754122]).

> [OSGi] HttpProxyConfigurationActivator does not unregister 
> HttpClientBuilderFactory
> ---
>
> Key: HTTPCLIENT-1773
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1773
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>    Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: 4.5.3
>
> Attachments: HTTPCLIENT-1773-jsedding.patch
>
>
> The {{HttpProxyConfigurationActivator}} does not unregister the   
> {{HttpClientBuilderFactory}} service when the bundle is stopped. This seems 
> to be a copy & past error, because the {{CachingHttpClientBuilderFactory}} 
> registration overrides the value of the field {{clientFactory}}, which before 
> holds the required registration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Comment Edited] (HTTPCLIENT-1773) [OSGi] HttpProxyConfigurationActivator does not unregister HttpClientBuilderFactory

[Julian Sedding (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15536393#comment-15536393
 ] 

Julian Sedding edited comment on HTTPCLIENT-1773 at 9/30/16 4:24 PM:
-

Fixed in 4.5.x [r1762930|https://svn.apache.org/r1762930].
The issue was already fixed in trunk as a side-effect of HTTPCLIENT-1752 
([r1754122|https://svn.apache.org/1754122]).

Note: I went for the easiest possible fix in order to not deviate from trunk 
too much. I will do any further refactorings in trunk first.


was (Author: jsedding):
Fixed in 4.5.x [r1762930|https://svn.apache.org/r1762930].
The issue was already fixed in trunk as a side-effect of HTTPCLIENT-1752 
([r1754122|https://svn.apache.org/1754122]).

> [OSGi] HttpProxyConfigurationActivator does not unregister 
> HttpClientBuilderFactory
> ---
>
> Key: HTTPCLIENT-1773
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1773
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>    Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: 4.5.3
>
> Attachments: HTTPCLIENT-1773-jsedding.patch
>
>
> The {{HttpProxyConfigurationActivator}} does not unregister the   
> {{HttpClientBuilderFactory}} service when the bundle is stopped. This seems 
> to be a copy & past error, because the {{CachingHttpClientBuilderFactory}} 
> registration overrides the value of the field {{clientFactory}}, which before 
> holds the required registration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1775) [OSGi] Proxy Configuration PID changed between 4.x and 5.x branches

[Julian Sedding (JIRA)]

Julian Sedding created HTTPCLIENT-1775:
--

 Summary: [OSGi] Proxy Configuration PID changed between 4.x and 
5.x branches
 Key: HTTPCLIENT-1775
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1775
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 5.0 Alpha1
Reporter: Julian Sedding
Assignee: Julian Sedding


The PID for the OSGi Proxy Configuration was changed between 4.x and 5.x.

As the PID is just an opaque string, there is no need to break existing proxy 
configurations with the update from 4.x to 5.x. Hence I suggest to revert the 
PID to its previous value.

Also, to stay consistent in the naming, I would change/revert the other PIDs to 
start with "org.apache.http."

WDYT, [~simone.tripodi]?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1772) [OSGi] WeakList needs to support "clear" method

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1772:
---
Attachment: HTTPCLIENT-1772-jsedding.patch

The patch [^HTTPCLIENT-1772-jsedding.patch] adds a tests for a working 
implementation of {{clear()}} and includes the fix for the issue.

> [OSGi] WeakList needs to support "clear" method
> ---
>
> Key: HTTPCLIENT-1772
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1772
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>Reporter: Julian Sedding
> Attachments: HTTPCLIENT-1772-jsedding.patch
>
>
> The {{WeakList}} implementation introduced in HTTPCLIENT-1749 does not 
> currently implement the {{close()}} method.
> However, {{HttpProxyConfigurationActivator}} calls this method when the OSGi 
> bundle is stopped, leading to an exception being thrown.
> {noformat}
> org.osgi.framework.BundleException: Activator stop error in bundle 
> org.apache.httpcomponents.httpclient [122].
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2663)
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2341)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:60)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:93)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:70)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:123)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.UnsupportedOperationException: null
> at java.util.AbstractList.remove(AbstractList.java:161)
> at java.util.AbstractList$Itr.remove(AbstractList.java:374)
> at java.util.AbstractList.removeRange(AbstractList.java:571)
> at java.util.AbstractList.clear(AbstractList.java:234)
> at 
> org.apache.http.osgi.impl.HttpProxyConfigurationActivator.stop(HttpProxyConfigurationActivator.java:140)
> at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2607)
> ... 7 common frames omitted
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1773) [OSGi] HttpProxyConfigurationActivator does not unregister HttpClientBuilderFactory

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1773:
---
Attachment: HTTPCLIENT-1773-jsedding.patch

The attached patch [^HTTPCLIENT-1773-jsedding.patch] replaces the individual 
field for service registrations with a list. This should help avoid future copy 
& paste issues.

> [OSGi] HttpProxyConfigurationActivator does not unregister 
> HttpClientBuilderFactory
> ---
>
> Key: HTTPCLIENT-1773
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1773
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>Reporter: Julian Sedding
> Attachments: HTTPCLIENT-1773-jsedding.patch
>
>
> The {{HttpProxyConfigurationActivator}} does not unregister the   
> {{HttpClientBuilderFactory}} service when the bundle is stopped. This seems 
> to be a copy & past error, because the {{CachingHttpClientBuilderFactory}} 
> registration overrides the value of the field {{clientFactory}}, which before 
> holds the required registration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1771) [OSGi] improve webconsole display for org.apache.http.proxyconfigurator

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed HTTPCLIENT-1771.
--

Thank you very much [~olegk] for the quick resolution! I tested a local build 
of the 4.5.x branch, it works as intended.

> [OSGi] improve webconsole display for org.apache.http.proxyconfigurator
> ---
>
> Key: HTTPCLIENT-1771
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1771
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>    Reporter: Julian Sedding
>Priority: Minor
> Fix For: 4.5.3, 5.0 Alpha2
>
> Attachments: HTTPCLIENT-1771-jsedding.patch, after.png, before.png
>
>
> Since version 4.2.6 the Felix webconsole supports "nameHints" for 
> configuration factories. These allow to display some of the configuration 
> values in the configuration webconsole pugin to allow easier identification 
> of configurations.
> The property {{webconsole.configurationFactory.nameHint}} should be added to 
> the metatype definition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1772) [OSGi] WeakList needs to support "clear" method

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1772.

   Resolution: Fixed
Fix Version/s: 5.0 Alpha2
   4.5.3

Fixed in trunk [r1762912|https://svn.apache.org/r1762912].
Fixed in 4.5.x [r1762913|https://svn.apache.org/r1762913].

> [OSGi] WeakList needs to support "clear" method
> ---
>
> Key: HTTPCLIENT-1772
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1772
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>Reporter: Julian Sedding
> Fix For: 4.5.3, 5.0 Alpha2
>
> Attachments: HTTPCLIENT-1772-jsedding.patch
>
>
> The {{WeakList}} implementation introduced in HTTPCLIENT-1749 does not 
> currently implement the {{close()}} method.
> However, {{HttpProxyConfigurationActivator}} calls this method when the OSGi 
> bundle is stopped, leading to an exception being thrown.
> {noformat}
> org.osgi.framework.BundleException: Activator stop error in bundle 
> org.apache.httpcomponents.httpclient [122].
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2663)
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2341)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:60)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:93)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:70)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:123)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.UnsupportedOperationException: null
> at java.util.AbstractList.remove(AbstractList.java:161)
> at java.util.AbstractList$Itr.remove(AbstractList.java:374)
> at java.util.AbstractList.removeRange(AbstractList.java:571)
> at java.util.AbstractList.clear(AbstractList.java:234)
> at 
> org.apache.http.osgi.impl.HttpProxyConfigurationActivator.stop(HttpProxyConfigurationActivator.java:140)
> at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2607)
> ... 7 common frames omitted
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1772) [OSGi] WeakList needs to support "clear" method

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed HTTPCLIENT-1772.
--

> [OSGi] WeakList needs to support "clear" method
> ---
>
> Key: HTTPCLIENT-1772
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1772
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: 4.5.3, 5.0 Alpha2
>
> Attachments: HTTPCLIENT-1772-jsedding.patch
>
>
> The {{WeakList}} implementation introduced in HTTPCLIENT-1749 does not 
> currently implement the {{close()}} method.
> However, {{HttpProxyConfigurationActivator}} calls this method when the OSGi 
> bundle is stopped, leading to an exception being thrown.
> {noformat}
> org.osgi.framework.BundleException: Activator stop error in bundle 
> org.apache.httpcomponents.httpclient [122].
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2663)
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2341)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:60)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:93)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:70)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:123)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.UnsupportedOperationException: null
> at java.util.AbstractList.remove(AbstractList.java:161)
> at java.util.AbstractList$Itr.remove(AbstractList.java:374)
> at java.util.AbstractList.removeRange(AbstractList.java:571)
> at java.util.AbstractList.clear(AbstractList.java:234)
> at 
> org.apache.http.osgi.impl.HttpProxyConfigurationActivator.stop(HttpProxyConfigurationActivator.java:140)
> at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2607)
> ... 7 common frames omitted
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Assigned] (HTTPCLIENT-1772) [OSGi] WeakList needs to support "clear" method

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding reassigned HTTPCLIENT-1772:
--

Assignee: Julian Sedding

> [OSGi] WeakList needs to support "clear" method
> ---
>
> Key: HTTPCLIENT-1772
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1772
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>Reporter: Julian Sedding
>Assignee: Julian Sedding
> Fix For: 4.5.3, 5.0 Alpha2
>
> Attachments: HTTPCLIENT-1772-jsedding.patch
>
>
> The {{WeakList}} implementation introduced in HTTPCLIENT-1749 does not 
> currently implement the {{close()}} method.
> However, {{HttpProxyConfigurationActivator}} calls this method when the OSGi 
> bundle is stopped, leading to an exception being thrown.
> {noformat}
> org.osgi.framework.BundleException: Activator stop error in bundle 
> org.apache.httpcomponents.httpclient [122].
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2663)
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2341)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:60)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:93)
> at 
> org.apache.felix.webconsole.internal.core.UpdateHelper.doRun(UpdateHelper.java:70)
> at 
> org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:123)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.UnsupportedOperationException: null
> at java.util.AbstractList.remove(AbstractList.java:161)
> at java.util.AbstractList$Itr.remove(AbstractList.java:374)
> at java.util.AbstractList.removeRange(AbstractList.java:571)
> at java.util.AbstractList.clear(AbstractList.java:234)
> at 
> org.apache.http.osgi.impl.HttpProxyConfigurationActivator.stop(HttpProxyConfigurationActivator.java:140)
> at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2607)
> ... 7 common frames omitted
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Assigned] (HTTPCLIENT-1787) OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding reassigned HTTPCLIENT-1787:
--

Assignee: Julian Sedding

> OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri
> --
>
> Key: HTTPCLIENT-1787
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1787
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
> Environment: OSGi
>Reporter: Srijan Bhatnagar
>Assignee: Julian Sedding
>
> OSGiHttpRoutePlanner seems to always set the "http" scheme for the proxy-ed 
> host instead of figuring it out from the original url.
> It should leverage target scheme while building proxy-ed uri.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1787) OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri

[Julian Sedding (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15656492#comment-15656492
 ] 

Julian Sedding commented on HTTPCLIENT-1787:


[~srbhatna] Thanks for your report. If I understand you correctly, then I think 
the issue you describe does not exist. I am successfully using httpclient-osgi, 
with a configured proxy, to make https requests to some social media APIs.

But maybe I misunderstand your problem. Could you maybe provide a test case, a 
starting point could be 
[TestOSGiHttpRoutePlanner|https://github.com/apache/httpclient/blob/4.5.x/httpclient-osgi/src/test/java/org/apache/http/osgi/impl/TestOSGiHttpRoutePlanner.java]?
 If that's not feasible, maybe at least a snippet of the code that's not 
working for you.

> OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri
> --
>
> Key: HTTPCLIENT-1787
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1787
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
> Environment: OSGi
>Reporter: Srijan Bhatnagar
>Assignee: Julian Sedding
>
> OSGiHttpRoutePlanner seems to always set the "http" scheme for the proxy-ed 
> host instead of figuring it out from the original url.
> It should leverage target scheme while building proxy-ed uri.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1791) Proxy exceptions not honoured in HttpClient-osgi module

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1791.

Resolution: Duplicate

This looks like a duplicate of HTTPCLIENT-1710.

[~krachi...@gmail.com] please reopen if the linked issue does not fix your 
problem.

> Proxy exceptions not honoured in HttpClient-osgi module
> ---
>
> Key: HTTPCLIENT-1791
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1791
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.1, 4.5.2
>Reporter: Rachit Kumar
>
> Please review [0].
> The determineProxy function is not honouring the exception list. It just 
> matches the http request with first item in the exception list and returns.
> [0] 
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.httpcomponents/httpclient-osgi/4.3.4/org/apache/http/osgi/impl/OSGiHttpRoutePlanner.java/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1864) [OSGi] Allow to configure the OSGi client default timeouts

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated HTTPCLIENT-1864:
---
Labels:   (was: stuck volunteers-wanted)

> [OSGi] Allow to configure the OSGi client default timeouts
> --
>
> Key: HTTPCLIENT-1864
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1864
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5
>Reporter: Timothee Maret
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Stuck
>
>
> The OSGI HTTP client currently comes with default connection and socket 
> timeouts.
> The default timeouts are infinite values. Those infinite timeouts imply that 
> a failing connection may hang forever wasting the associated resources and 
> potentially causing the process to stop with hardly reproducible issues.
> There already is a way to configure the timeouts per client instance. This 
> approach provides a great flexibility but it comes at the cost of I. tedious 
> and error prone configurations, II. not solving the issue once for all (new 
> components may forget to add support for timeouts).
> Allowing to configure the default globally or via the factory configuration 
> (with defaults) would give a simpler configuration overall and inherit the 
> configurable default to all consumers of the client.
> This improvement shall only applies to the OSGI client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1864) [OSGi] Allow to configure the OSGi client default timeouts

[Julian Sedding (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1641#comment-1641
 ] 

Julian Sedding commented on HTTPCLIENT-1864:


[~marett] I have an experimental bundle with support for injecting 
pre-configured HttpClient instances via OSGi service registry (install in 
addition to httpclient-osgi). Check out 
https://github.com/code-distillery/httpclient-configuration-support and let me 
know if that looks interesting. I am planning to contribute this back to the 
httpclient-osgi project once I am happy with it and when I find the time.

> [OSGi] Allow to configure the OSGi client default timeouts
> --
>
> Key: HTTPCLIENT-1864
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1864
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5
>Reporter: Timothee Maret
>Priority: Minor
> Fix For: Stuck
>
>
> The OSGI HTTP client currently comes with default connection and socket 
> timeouts.
> The default timeouts are infinite values. Those infinite timeouts imply that 
> a failing connection may hang forever wasting the associated resources and 
> potentially causing the process to stop with hardly reproducible issues.
> There already is a way to configure the timeouts per client instance. This 
> approach provides a great flexibility but it comes at the cost of I. tedious 
> and error prone configurations, II. not solving the issue once for all (new 
> components may forget to add support for timeouts).
> Allowing to configure the default globally or via the factory configuration 
> (with defaults) would give a simpler configuration overall and inherit the 
> configurable default to all consumers of the client.
> This improvement shall only applies to the OSGI client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Assigned] (HTTPCLIENT-1864) [OSGi] Allow to configure the OSGi client default timeouts

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding reassigned HTTPCLIENT-1864:
--

Assignee: Julian Sedding

> [OSGi] Allow to configure the OSGi client default timeouts
> --
>
> Key: HTTPCLIENT-1864
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1864
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5
>Reporter: Timothee Maret
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Stuck
>
>
> The OSGI HTTP client currently comes with default connection and socket 
> timeouts.
> The default timeouts are infinite values. Those infinite timeouts imply that 
> a failing connection may hang forever wasting the associated resources and 
> potentially causing the process to stop with hardly reproducible issues.
> There already is a way to configure the timeouts per client instance. This 
> approach provides a great flexibility but it comes at the cost of I. tedious 
> and error prone configurations, II. not solving the issue once for all (new 
> components may forget to add support for timeouts).
> Allowing to configure the default globally or via the factory configuration 
> (with defaults) would give a simpler configuration overall and inherit the 
> configurable default to all consumers of the client.
> This improvement shall only applies to the OSGI client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-1787) OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1787.

Resolution: Cannot Reproduce

Closing this as there was no reply to clarify the issue.

> OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri
> --
>
> Key: HTTPCLIENT-1787
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1787
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
> Environment: OSGi
>Reporter: Srijan Bhatnagar
>Assignee: Julian Sedding
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> OSGiHttpRoutePlanner seems to always set the "http" scheme for the proxy-ed 
> host instead of figuring it out from the original url.
> It should leverage target scheme while building proxy-ed uri.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org