Re: Is Bugzilla mail broken? was [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Oleg Kalnichevski]

It does seem to be broken. We might need to drop a line at
[EMAIL PROTECTED] or [EMAIL PROTECTED] On the other hand I assume
that with Bugzilla being such a critical system for so many projects the
problem should have already been reported. I seriously doubt that
HttpClient is the only project affected.

Oleg


On Fri, 2003-09-05 at 22:15, Michael Becke wrote:
> It seems that Bugzilla is not sending email for some reason.  Anyone 
> have some insight into this?
> 
> Mike
> 
> Adam R. B. Jack wrote:
> 
> >>I updated the bug database (I believe) so this is posted there.
> > 
> > 
> > FWIIW: I do not believe I am receiving e-mails from the bug tracker. Are
> > other folks? Did you get my update?
> > 
> > regards
> > 
> > Adam
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Is Bugzilla mail broken? was [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Michael Becke]

It seems that Bugzilla is not sending email for some reason.  Anyone 
have some insight into this?

Mike

Adam R. B. Jack wrote:

I updated the bug database (I believe) so this is posted there.


FWIIW: I do not believe I am receiving e-mails from the bug tracker. Are
other folks? Did you get my update?
regards

Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Adam R. B. Jack]

> I updated the bug database (I believe) so this is posted there.

FWIIW: I do not believe I am receiving e-mails from the bug tracker. Are
other folks? Did you get my update?

regards

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22926] - [patch] Support for digest auth MD5-sess

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22926

[patch] Support for digest auth MD5-sess





--- Additional Comments From [EMAIL PROTECTED]  2003-09-04 19:02 ---
Hey, thanks for the pointers.  It was pretty late when I did this and I
completely guessed about how you'd want this.  I attached a new patch without
tabs and with the junit test.  Having run the junit test, I found something else
I'd broken in the digest stuff (assuming algorithm would be passed in, which is
not required).

I'm not sure I'm completely comfortable with the unit tests, however, as they
only  seem to test that the authenticator and the digest get the same result,
not that the result is correct.  It would probably be a good idea to do a
similar set of digest tests that include an expected digest response to validate
the algorithms as well.

That said, it's lunch time.  :)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Adam R. B. Jack]

Oleg wrote:

> We will be more than happy to play by the rules, as long as they are
clearly articulated and agreed upon, not just imposed upon us.

I completely agree, and like I said -- these aren't even "mandatory rules"
more "here is how to play nicely w/ other Gumpers". I also agree it is upon
the Gump folk to agree and document/communicate these things. I think this
has been in the heads of "those in the know" for too long...

> There is one thing I really have an issue with: why do we have to have
separate CVS
> modules per version under development, where a more natural way for me
(very GUMP
> illiterate person) is to have a CVS branch per version being developed. It
may happen that
> we will end up having yet another development stream in addition to
version 2.0 and 2.1
> development. Would that require yet another CVS module to remain GUMP
friendly?

Yikes, did I communicate this? No, not at all! I think we have a terminology
miscommunication...

Upon investigating how I see that one has to have multiple gump module
descriptors for separate tags/branches in one CVS module, but that is
doable. I beleive you can "alias" (via depends) to set the
commons-httpclient to any one of your two (or three) tags. I will find some
time to check this all out, and write it up/document it on the gump site.

That said, the Jakarta POI recently did this with two module descriptors,
but the same effect (although no aliasing):

http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi.xml?rev=1.29&content-type=text/vnd.viewcvs-markup
se http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi3.xml?rev=1.4&content-type=text/vnd.viewcvs-markup


There are (at least) two ways to get a tag/branch for a module (I am still
investigating on project). For reference see:

http://jakarta.apache.org/gump/module.html w/ the "tag" on module and the
"cvs" information.

IF you look here I think you'll see a number of such examples:

http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/#dirlist

As I said, I care about this sort of stuff so am happy to try to help and/or
document.

regards,

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Kalnichevski, Oleg]

> Nobody said that you need a cvs module per development branch (and I have no 
> idea where you'd get that from...). 

I am glad I have misunderstood (or misinterpreted) Adam's statement.

> (The name "Gump" is not an abbreviation BTW)

My apologies who felt insulted by that

Chris, Adam

Please advise us how to set up Gump project files for HttpClient 2.0 & HttpClient HEAD 
in order to be as Gump friendly as possible

Oleg

PS: Sorry about having sent an empty response before

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Kalnichevski, Oleg]

-Original Message-
From: Christopher Lenz [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 7:09 PM
To: Commons HttpClient Project
Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()


Kalnichevski, Oleg wrote:
> Adam,
> We will be more than happy to play by the rules, as long as they are clearly 
> articulated and agreed upon, not just imposed upon us. There is one thing I really 
> have an issue with: why do we have to have separate CVS modules per version under 
> development, where a more natural way for me (very GUMP illiterate person) is to 
> have a CVS branch per version being developed. It may happen that we will end up 
> having yet another development stream in addition to version 2.0 and 2.1 
> development. Would that require yet another CVS module to remain GUMP friendly?

Nobody said that you need a cvs module per development branch (and I have no 
idea where you'd get that from...). Gump lets you specify CVS branches/tags, 
it's just that many "Gump folks" see such requests as a sign of something 
else going wrong (for example, projects not playing nicely with the others). 
That being said, it would probably make sense to set up a 
commons-httpclient-2.0 project in gump, which would be based on the 
maintenance branch.

-chris

(The name "Gump" is not an abbreviation BTW)

> 
> Or am I just missing something? Please advise.
> 
> Oleg
> 
> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 05, 2003 6:30 PM
> To: Commons HttpClient Project
> Cc: [EMAIL PROTECTED]
> Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
> 
> 
> Oleg wrote:
> 
> 
>>Adam, with all due respect let me point out that we have stable
>>HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API
>>and/or code stability. If GUMP cannot be configured to use any other CVS
> 
> branch but
> 
>>HEAD, this is a totally different kind of a problem, and it should be
> 
> brought up to GUMP
> 
>>folks, not to us.
> 
> 
> Gump can be configured, but it is community configured, and your project has
> selected this configuration.
> 
> I am (very recently) a "gump folk", although still learning -- and these
> opionions are most definately, my own -- however I think we are discussing
> "Gump ettiquette". I think your project unwittingly did something a bit
> unfriendly, and I'd like to cultivate a "gump how-to" or
> "how-to-be-a-friend-of-gump" that helps you/other projects from doing the
> same in the future.
> 
> I care because I feel Gump supports inter-community respect, and project
> collaboration, and I want projects to depend upon each other more, not less.
> 
> Gump's philosophy is to use CVS HEAD, and does so by default. You could've
> set your project to use the stable tag, but without it you involved all your
> dependees in any major changes. Now debatably this is a good thing, it helps
> you find the problems, but as your list of dependees gets long (and I hope
> it does :-) and if things fail, then this stops a whole sub-tree of Gump
> from Gumping ... and hence is detrimental to the community. As such, a
> separate transition project (one for stable, one for CVS HEAD) allows you
> and sub-projects to decide when to "test the new stuff" and you (via
> aliasing) can decide "when to flip the switch".
> 
> As for having unit tests run in the gump project, there are three schools of
> thought. First says don't do them, Gump is for compiling -- unit tests cost
> Gump CPU, but I disagree -- and I hope most folks do. Second is -- add them
> to your main project. Third says -- create a separate xxx-test project for
> your unit tests. The logic behind the third (which I am becoming a fan of)
> is that dependees can then chose to depend upon xxx or also upon xxx-test.
> Typically unit tests are very strict, so depending upon xxx-test might cause
> wasted gumping (a compile error might not be found due to some obscure unit
> test failing), so folks would normally not depend upon xxx-test (their
> yyy-test would find it) unless they felt xxx was unstable, and then they
> could.
> 
> I think these are nuance of using Gump that escapes most Gump project
> configurer [I am just getting them], and I think it needs to be address via
> some sort of "FriendOfGump" guidelines documentation on Gump. I am copying
> the Gump list for their input, and if a conscensus is there I'll try to
> write up the documentaton.
> 
> regards
> 
> Adam
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PRO

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Christopher Lenz]

Kalnichevski, Oleg wrote:
Adam,
We will be more than happy to play by the rules, as long as they are clearly 
articulated and agreed upon, not just imposed upon us. There is one thing I really 
have an issue with: why do we have to have separate CVS modules per version under 
development, where a more natural way for me (very GUMP illiterate person) is to have 
a CVS branch per version being developed. It may happen that we will end up having yet 
another development stream in addition to version 2.0 and 2.1 development. Would that 
require yet another CVS module to remain GUMP friendly?
Nobody said that you need a cvs module per development branch (and I have no 
idea where you'd get that from...). Gump lets you specify CVS branches/tags, 
it's just that many "Gump folks" see such requests as a sign of something 
else going wrong (for example, projects not playing nicely with the others). 
That being said, it would probably make sense to set up a 
commons-httpclient-2.0 project in gump, which would be based on the 
maintenance branch.

-chris

(The name "Gump" is not an abbreviation BTW)

Or am I just missing something? Please advise.

Oleg

-Original Message-
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 6:30 PM
To: Commons HttpClient Project
Cc: [EMAIL PROTECTED]
Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Oleg wrote:


Adam, with all due respect let me point out that we have stable
HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API
and/or code stability. If GUMP cannot be configured to use any other CVS
branch but

HEAD, this is a totally different kind of a problem, and it should be
brought up to GUMP

folks, not to us.


Gump can be configured, but it is community configured, and your project has
selected this configuration.
I am (very recently) a "gump folk", although still learning -- and these
opionions are most definately, my own -- however I think we are discussing
"Gump ettiquette". I think your project unwittingly did something a bit
unfriendly, and I'd like to cultivate a "gump how-to" or
"how-to-be-a-friend-of-gump" that helps you/other projects from doing the
same in the future.
I care because I feel Gump supports inter-community respect, and project
collaboration, and I want projects to depend upon each other more, not less.
Gump's philosophy is to use CVS HEAD, and does so by default. You could've
set your project to use the stable tag, but without it you involved all your
dependees in any major changes. Now debatably this is a good thing, it helps
you find the problems, but as your list of dependees gets long (and I hope
it does :-) and if things fail, then this stops a whole sub-tree of Gump
from Gumping ... and hence is detrimental to the community. As such, a
separate transition project (one for stable, one for CVS HEAD) allows you
and sub-projects to decide when to "test the new stuff" and you (via
aliasing) can decide "when to flip the switch".
As for having unit tests run in the gump project, there are three schools of
thought. First says don't do them, Gump is for compiling -- unit tests cost
Gump CPU, but I disagree -- and I hope most folks do. Second is -- add them
to your main project. Third says -- create a separate xxx-test project for
your unit tests. The logic behind the third (which I am becoming a fan of)
is that dependees can then chose to depend upon xxx or also upon xxx-test.
Typically unit tests are very strict, so depending upon xxx-test might cause
wasted gumping (a compile error might not be found due to some obscure unit
test failing), so folks would normally not depend upon xxx-test (their
yyy-test would find it) unless they felt xxx was unstable, and then they
could.
I think these are nuance of using Gump that escapes most Gump project
configurer [I am just getting them], and I think it needs to be address via
some sort of "FriendOfGump" guidelines documentation on Gump. I am copying
the Gump list for their input, and if a conscensus is there I'll try to
write up the documentaton.
regards

Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Kalnichevski, Oleg]

Adam,
We will be more than happy to play by the rules, as long as they are clearly 
articulated and agreed upon, not just imposed upon us. There is one thing I really 
have an issue with: why do we have to have separate CVS modules per version under 
development, where a more natural way for me (very GUMP illiterate person) is to have 
a CVS branch per version being developed. It may happen that we will end up having yet 
another development stream in addition to version 2.0 and 2.1 development. Would that 
require yet another CVS module to remain GUMP friendly?

Or am I just missing something? Please advise.

Oleg

-Original Message-
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 6:30 PM
To: Commons HttpClient Project
Cc: [EMAIL PROTECTED]
Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()


Oleg wrote:

> Adam, with all due respect let me point out that we have stable
> HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API
> and/or code stability. If GUMP cannot be configured to use any other CVS
branch but
> HEAD, this is a totally different kind of a problem, and it should be
brought up to GUMP
> folks, not to us.

Gump can be configured, but it is community configured, and your project has
selected this configuration.

I am (very recently) a "gump folk", although still learning -- and these
opionions are most definately, my own -- however I think we are discussing
"Gump ettiquette". I think your project unwittingly did something a bit
unfriendly, and I'd like to cultivate a "gump how-to" or
"how-to-be-a-friend-of-gump" that helps you/other projects from doing the
same in the future.

I care because I feel Gump supports inter-community respect, and project
collaboration, and I want projects to depend upon each other more, not less.

Gump's philosophy is to use CVS HEAD, and does so by default. You could've
set your project to use the stable tag, but without it you involved all your
dependees in any major changes. Now debatably this is a good thing, it helps
you find the problems, but as your list of dependees gets long (and I hope
it does :-) and if things fail, then this stops a whole sub-tree of Gump
from Gumping ... and hence is detrimental to the community. As such, a
separate transition project (one for stable, one for CVS HEAD) allows you
and sub-projects to decide when to "test the new stuff" and you (via
aliasing) can decide "when to flip the switch".

As for having unit tests run in the gump project, there are three schools of
thought. First says don't do them, Gump is for compiling -- unit tests cost
Gump CPU, but I disagree -- and I hope most folks do. Second is -- add them
to your main project. Third says -- create a separate xxx-test project for
your unit tests. The logic behind the third (which I am becoming a fan of)
is that dependees can then chose to depend upon xxx or also upon xxx-test.
Typically unit tests are very strict, so depending upon xxx-test might cause
wasted gumping (a compile error might not be found due to some obscure unit
test failing), so folks would normally not depend upon xxx-test (their
yyy-test would find it) unless they felt xxx was unstable, and then they
could.

I think these are nuance of using Gump that escapes most Gump project
configurer [I am just getting them], and I think it needs to be address via
some sort of "FriendOfGump" guidelines documentation on Gump. I am copying
the Gump list for their input, and if a conscensus is there I'll try to
write up the documentaton.

regards

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Adam R. B. Jack]

Oleg wrote:

> Adam, with all due respect let me point out that we have stable
> HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API
> and/or code stability. If GUMP cannot be configured to use any other CVS
branch but
> HEAD, this is a totally different kind of a problem, and it should be
brought up to GUMP
> folks, not to us.

Gump can be configured, but it is community configured, and your project has
selected this configuration.

I am (very recently) a "gump folk", although still learning -- and these
opionions are most definately, my own -- however I think we are discussing
"Gump ettiquette". I think your project unwittingly did something a bit
unfriendly, and I'd like to cultivate a "gump how-to" or
"how-to-be-a-friend-of-gump" that helps you/other projects from doing the
same in the future.

I care because I feel Gump supports inter-community respect, and project
collaboration, and I want projects to depend upon each other more, not less.

Gump's philosophy is to use CVS HEAD, and does so by default. You could've
set your project to use the stable tag, but without it you involved all your
dependees in any major changes. Now debatably this is a good thing, it helps
you find the problems, but as your list of dependees gets long (and I hope
it does :-) and if things fail, then this stops a whole sub-tree of Gump
from Gumping ... and hence is detrimental to the community. As such, a
separate transition project (one for stable, one for CVS HEAD) allows you
and sub-projects to decide when to "test the new stuff" and you (via
aliasing) can decide "when to flip the switch".

As for having unit tests run in the gump project, there are three schools of
thought. First says don't do them, Gump is for compiling -- unit tests cost
Gump CPU, but I disagree -- and I hope most folks do. Second is -- add them
to your main project. Third says -- create a separate xxx-test project for
your unit tests. The logic behind the third (which I am becoming a fan of)
is that dependees can then chose to depend upon xxx or also upon xxx-test.
Typically unit tests are very strict, so depending upon xxx-test might cause
wasted gumping (a compile error might not be found due to some obscure unit
test failing), so folks would normally not depend upon xxx-test (their
yyy-test would find it) unless they felt xxx was unstable, and then they
could.

I think these are nuance of using Gump that escapes most Gump project
configurer [I am just getting them], and I think it needs to be address via
some sort of "FriendOfGump" guidelines documentation on Gump. I am copying
the Gump list for their input, and if a conscensus is there I'll try to
write up the documentaton.

regards

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Kalnichevski, Oleg]

> BTW: I don't mind bugs, in any complex software there will be bugs, but I
> feel it is only "polite" to have (1) test projects on gump -- that run your
> unit tests [so I can 'depend upon them'] (2) transition projects on gump
> when you are doing a big re-work, so you control when folks get exposed to
> the new work. Folks like VFS just don't tinker w/ their code  that often,
> and so if this had been (or is) something inside their usage it could fester
> for a while. Since you chose to move them to CVS HEAD (for Gump) and since
> they don't run their unit tests (either) then my projects fail in Gump.

Adam, with all due respect let me point out that we have stable HTTPCLIENT_2_0_BRANCH 
branch that should be used by those who need API and/or code stability. If GUMP cannot 
be configured to use any other CVS branch but HEAD, this is a totally different kind 
of a problem, and it should be brought up to GUMP folks, not to us.

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Michael Becke]

Hi Adam,

No worries.  I agree with you that connection.getProtocol().getScheme() 
is where the NPE is occuring.  This means that either the connection or 
the protocol are null.  From looking through the code and running 
various tests I am unsure of how this could happen.  My guess is that 
the cause is how VFS is configuring/using HttpClient.  If you could help 
to shed some light on what VFS is attempting I'm sure we will be able to 
find a solution.

Thanks,

Mike

Adam R. B. Jack wrote:

Mike wrote:


I must disagree with you here.  I responded to your bug report about 5
hours after you posted it.   I was unable to reproduce this problem
given the details you have provided.  If you have some more detail
about how to reproduce this problem, or perhaps a wire log, I would be
happy to continue helping.



Hmm, sorry Mike, I don't beleive I received notification of that. I
certainly wasn't aware of the response. Sorry I didn't go look.
The crash that I get (still w/ latest CVS HEAD) is that  in
HttpMethodDirector.procesRedirectResponse the connection returns null fir
pretty much everything, including Protocol. As such it crashes in:
connection.getProtocol().getScheme() on line 460.
I will take your sample and attempt to reproduce it here. Unfortunately (for
debugging this) I am using Commons VFS, which in turn uses HttpClient, so
maybe it is some usage/re-usage/configuration sequence that causes this. I
will see what I can do to reproduce.
regards,

Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Adam R. B. Jack]

> I will take your sample and attempt to reproduce it here. Unfortunately
(for
> debugging this) I am using Commons VFS, which in turn uses HttpClient, so
> maybe it is some usage/re-usage/configuration sequence that causes this. I
> will see what I can do to reproduce.

I found the settings that VFS was using, and tried to emulate. It seems to
need the MultiThreadedHttpConnectionManager plus HEAD to crash.

  HttpClient client = new HttpClient(new
MultiThreadedHttpConnectionManager());
  HeadMethod head = new HeadMethod(url);
  client.executeMethod(head);

I updated the bug database (I believe) so this is posted there.

BTW: I don't mind bugs, in any complex software there will be bugs, but I
feel it is only "polite" to have (1) test projects on gump -- that run your
unit tests [so I can 'depend upon them'] (2) transition projects on gump
when you are doing a big re-work, so you control when folks get exposed to
the new work. Folks like VFS just don't tinker w/ their code  that often,
and so if this had been (or is) something inside their usage it could fester
for a while. Since you chose to move them to CVS HEAD (for Gump) and since
they don't run their unit tests (either) then my projects fail in Gump.

Just a request...

regards,

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Adam R. B. Jack]

Mike wrote:

> I must disagree with you here.  I responded to your bug report about 5
> hours after you posted it.   I was unable to reproduce this problem
> given the details you have provided.  If you have some more detail
> about how to reproduce this problem, or perhaps a wire log, I would be
> happy to continue helping.
>
> 

Hmm, sorry Mike, I don't beleive I received notification of that. I
certainly wasn't aware of the response. Sorry I didn't go look.

The crash that I get (still w/ latest CVS HEAD) is that  in
HttpMethodDirector.procesRedirectResponse the connection returns null fir
pretty much everything, including Protocol. As such it crashes in:
connection.getProtocol().getScheme() on line 460.

I will take your sample and attempt to reproduce it here. Unfortunately (for
debugging this) I am using Commons VFS, which in turn uses HttpClient, so
maybe it is some usage/re-usage/configuration sequence that causes this. I
will see what I can do to reproduce.

regards,

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Michael Becke]

Hi Adam,

On Friday, September 5, 2003, at 12:01 AM, Adam R. B. Jack wrote:

From my perspective, it fizzled and died here. I logged a bug report on
HttpClient (on one crash I received) but I don't believe any action has
occurred.
I must disagree with you here.  I responded to your bug report about 5 
hours after you posted it.   I was unable to reproduce this problem 
given the details you have provided.  If you have some more detail 
about how to reproduce this problem, or perhaps a wire log, I would be 
happy to continue helping.



Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with bug tracking system?

[Ortwin Glück]

Roland Weber wrote:
there may be some problem with the bug tracking system's
connection to the mailing list. I did not receive mails for the
last three or four comments 
I see a similar effect. I do not get all messages. And since a couple of 
days (those you come through) they get sent to me directly as well as 
the list.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problem with bug tracking system?

[Roland Weber]

Hello folks,

there may be some problem with the bug tracking system's
connection to the mailing list. I did not receive mails for the
last three or four comments added to this issue:

New Preferences Architecture
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435

If you are following this discussion, or that of some other bug,
you may want to check the respective web site directly.

regards,
  Roland

Re: setBodyCheckTimeout causes problems in closing the connection

[[EMAIL PROTECTED]]

Hi,
thank you very much for your reply..
actually, when I'm using the 2.0 build I get this log, in which it looks 
like there is a second attempt to wait for the non-complaint response 
body, but no exception is thrown (i'm just pasting the relevant portions 
here):

1213   DEBUG [Thread-1] methods.HeadMethod - enter 
HeadMethod.readResponseBody(HttpState, HttpConnection)
1213   DEBUG [Thread-1] methods.HeadMethod - Check for non-compliant 
response body. Timeout in 500 ms
1214   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.isResponseAvailable(int)
1216   DEBUG [Thread-1] httpclient.HttpConnection - Input data not available
1217   DEBUG [Thread-1] httpclient.HttpMethodBase - Closing the connection.
1217   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.close()
1217   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.closeSockedAndStreams()
1218   INFO  [Thread-1] httpclient.HttpMethodBase - Recoverable 
exception caught when processing request
1222   DEBUG [Thread-1] httpclient.HttpMethodBase - Attempt number 2 to 
process request
1222   DEBUG [Thread-1] httpclient.HttpMethodBase - Opening the connection.
1222   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.open()
1363   DEBUG [Thread-1] httpclient.HttpMethodBase - enter 
HttpMethodBase.writeRequest(HttpState, HttpConnection)
1364   DEBUG [Thread-1] httpclient.HttpMethodBase - enter 
HttpMethodBase.writeRequestLine(HttpState, HttpConnection)
1364   DEBUG [Thread-1] httpclient.HttpMethodBase - enter 
HttpMethodBase.generateRequestLine(HttpConnection, String, String, 
String, String)
1364   DEBUG [Thread-1] httpclient.wire - >> "HEAD 
/info/about/peerreview HTTP/1.1[\r][\n]"

1564   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.flushRequestOutputStream()
1564   DEBUG [Thread-1] httpclient.HttpMethodBase - enter 
HttpMethodBase.readResponse(HttpState, HttpConnection)
1564   DEBUG [Thread-1] methods.HeadMethod - enter 
HeadMethod.readResponseBody(HttpState, HttpConnection)
1564   DEBUG [Thread-1] methods.HeadMethod - Check for non-compliant 
response body. Timeout in 500 ms
1564   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.isResponseAvailable(int)
1646   DEBUG [Thread-1] httpclient.HttpConnection - Input data available
1647   WARN  [Thread-1] methods.HeadMethod - Body content returned in 
response to HTTP HEAD
1648   DEBUG [Thread-1] httpclient.HttpMethodBase - enter 
HttpMethodBase.readResponseBody(HttpState, HttpConnection)
1648   DEBUG [Thread-1] httpclient.HttpMethodBase - enter 
HttpMethodBase.readResponseBody(HttpState, HttpConnection)
1648   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.getResponseInputStream()
1649   DEBUG [Thread-1] httpclient.HttpMethodBase - enter 
HttpMethodBase.canResponseHaveBody(int)
1652   DEBUG [Thread-1] httpclient.HttpMethodBase - Should forcefully 
close connection.
1653   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.close()
1653   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.closeSockedAndStreams()
1653   DEBUG [Thread-1] httpclient.HttpConnection - enter 
HttpConnection.releaseConnection()

I confirm that setting setBodyCheckTimeout(-1) eliminates this behaviour 
 when using 2.0 biuld, as well as the exception being thrown when using 
the 2.1 build.

In my version of EasyX509TrustManager I just let isServerTrusted() to 
always return true, but I don't know if this can impact the problem:

public class EasyX509TrustManager implements X509TrustManager
{
private X509TrustManager standardTrustManager = null;
/** Log object for this class. */
private static final Log LOG = 
LogFactory.getLog(EasyX509TrustManager.class);

/**
 * Constructor for EasyX509TrustManager.
 */
public EasyX509TrustManager(KeyStore keystore) throws 
NoSuchAlgorithmException, KeyStoreException {
super();
TrustManagerFactory factory = 
TrustManagerFactory.getInstance("SunX509");
factory.init(keystore);
TrustManager[] trustmanagers = factory.getTrustManagers();
if (trustmanagers.length == 0) {
throw new NoSuchAlgorithmException("SunX509 trust manager 
not supported");
}
this.standardTrustManager = (X509TrustManager)trustmanagers[0];
}

/**
 * @see 
com.sun.net.ssl.X509TrustManager#isClientTrusted(X509Certificate[])
 */
public boolean isClientTrusted(X509Certificate[] certificates) {
return this.standardTrustManager.isClientTrusted(certificates);
}

/**
 * @see 
com.sun.net.ssl.X509TrustManager#isServerTrusted(X509Certificate[])
 */
public boolean isServerTrusted(X509Certificate[] certificates) {
if ((certificates != null) && LOG.isDebugEnabled()) {
LOG.debug("Server certificate chain:");
for (int i = 0; i < certificates.length; i++) {
LOG.debug("X509Certificate[" + i + "]=" + ce

RE: Release date for httpclient 2.0 final?

[Vincent Massol]

Hi Oleg,

> -Original Message-
> From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
> Sent: 04 September 2003 22:38
> To: Commons HttpClient Project
> Cc: Vincent Massol
> Subject: RE: Release date for httpclient 2.0 final?
> 
> Vincent,
> 
> Truth to be told, I see late September as not impossible but highly
> unlikely 2.0 final release date. We have had way too many bug reports
> recently (nothing really critical but just too many) to be in a
position
> to rush the final release. There will be at least RC2 and RC3.
Besides,
> there is still one major task to be finished: javadoc cleanup. It is a
> painfully slow and unpleasant undertaking. It will take a few rainy
> weekends. I fear there may be no final release until late October -
mid
> November. Yet, I will be glad to be proven wrong.
> 
> When is your book to go to print?

It will go to print in about 2 weeks from now. It should be available
for general consumption around 2nd week of October. Which means 2.0 will
ptobably not be out yet.

Ok, then my anticipation was not quite correct (but close)... I'll
probably still keep the 2.0 reference in screenshots but I'll make a
note about the RC versions in the appendix defining which software
versions to use while running the book examples.

Thanks
-Vincent

[snip]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release date for httpclient 2.0 final?

[Ortwin Glück]

Oleg Kalnichevski wrote:
[javadoc] It is a
painfully slow and unpleasant undertaking. It will take a few rainy
weekends. I fear there may be no final release until late October - mid
November. 
Sounds realistic too, as the rainy weekends have been quite sparse in 
Switzerland recently...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]