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

[Stefan Bodewig]

On Mon, 8 Sep 2003, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:

> However, most of my statement (and now question) is about
> friend-of-gump behaviour, and having that project is good, but not
> "friendly" 'cos it forces work onto sub-projects.

I'm not sure.

> Do you not agree that the project should manage itself, should
> create the new (temporarily unstable) codebase as the sub-named
> project, and should either alias (via  name="commons-httpclient" ..  name="commons-httpclient-old-stable-branch" inherit="all") or rename
> projects in order to manage it for folk?

It would be nice if they did.

Many projects consider Gump either a community service maintained by
others (most committers don't even know they have commit access to the
jakarta-gump module) or a nuisance.

I think it is perfectly legitimate for a project to move forward and
break backwards compatibility after a deprecation period that's been
long enough and included at least one stable release.  Whether such a
project decides to move forward in CVS HEAD or in a branch is up to
its committers.  If they manage its Gump descriptor to take the
problem into account is a different issue - see above.

Stefan

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

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

[Stefan Bodewig]

On Fri, 5 Sep 2003, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> 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.

Please note that there already is a commons-httpclient-2.0-branch
project in Gump's workspace.  It would be trivial for projects to
depend on that branch instead of CVS HEAD and in fact jakarta-slide
and xml-rpc already do so.

Stefan

-
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]

Stefan wrote:

>
> Please note that there already is a commons-httpclient-2.0-branch
> project in Gump's workspace.  It would be trivial for projects to
> depend on that branch instead of CVS HEAD and in fact jakarta-slide
> and xml-rpc already do so.
>

Thanks, I'd not seen that.

However, most of my statement (and now question) is about friend-of-gump
behaviour, and having that project is good, but not "friendly" 'cos it
forces work onto sub-projects. Do you not agree that the project should
manage itself, should create the new (temporarily unstable) codebase as the
sub-named project, and should either alias (via 

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]

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 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: [VFS|HttpClient] Re: [VFS] Crashes in getContent()

[Adam R. B. Jack]

> Folks, what was the outcome of this discussion?

>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. The Krysalis stack of projects still fail nightly on Gump with
VFS/HttpClient. Please see:

http://cvs.apache.org/builds/gump/latest/krysalis-version.html
http://cvs.apache.org/builds/gump/latest/krysalis-centipede-site.html

That said, these here look like VFS crashes, however I believe they are due
to an earlier HttpClient crash. The stack I logged went into HttpClient and
crashed there, something to do with processing a simple redirect.

BTW: The lack of progress on this has finally pushed me to begin a re-write
of Krysalis Ruper to make VFS & HttpClient optional. The re-write is a good
thing for itself, but the inability to rely upon this foundation is
disappointing.

regards

Adam


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

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

[Oleg Kalnichevski]

> Would it be possible for you to make the commons-httpclient project in gump
> be 2.0, and start a commons-httpclient-21 project for those brave enough to
> gump against it during alpha phase? When 2.1 is stable you could switch the
> main project to 2.1.
> 
> I know Gump wants to integrate the latest/greatest, but when that isn't
> stable that isn't practical. What if folks (say VFS) tried to change their
> code to mend breaks on gump, and then you changed things again, that is a
> lot of busy work.
> 

Folks, what was the outcome of this discussion?

Oleg



-
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:


> Yes, it looks like you are using HttpClient from HEAD.  2.0 code has
> been moved into a branch and we've started 2.1 in HEAD.  All unit
tests
> are passing but HEAD contains essentially alpha code.  If you are
> looking for something stable I suggest 2.0.  Mostly likely there is a
> bug in HEAD.  Please submit a bug in Bugzilla when you get a chance.

I can understand the reasoning to use HEAD for latest stuff, and I
appreciate it being alpha code & the benefits of starting some brave/risky
new work for a new release. What I am wondering however is the choice of
impact on gump until you are more stable . I don't have access to a VFS
committer, and I am sure there are a bunch of httpclient dependencies that
haven't had chance to chose their basis, you've made the choice for them by
having the main common-httpclient be 2.1.

Would it be possible for you to make the commons-httpclient project in gump
be 2.0, and start a commons-httpclient-21 project for those brave enough to
gump against it during alpha phase? When 2.1 is stable you could switch the
main project to 2.1.

I know Gump wants to integrate the latest/greatest, but when that isn't
stable that isn't practical. What if folks (say VFS) tried to change their
code to mend breaks on gump, and then you changed things again, that is a
lot of busy work.

I am not sure if there is a Gump Guideline for doing things the way I am
request, but I've seen others do it.

Thanks in advance for any consideration you can give this.

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]

Yes, it looks like you are using HttpClient from HEAD.  2.0 code has  
been moved into a branch and we've started 2.1 in HEAD.  All unit tests  
are passing but HEAD contains essentially alpha code.  If you are  
looking for something stable I suggest 2.0.  Mostly likely there is a  
bug in HEAD.  Please submit a bug in Bugzilla when you get a chance.

Mike

On Thursday, August 21, 2003, at 09:07 PM, Adam R. B. Jack wrote:

Thanks for that information, some project have separate test suite  
projects,
so I wondered. If it could be replace that'd be great 'cos I'd like to  
see
tests succeed on Gump (on latest stack below) not only on developers
machines. It is Gump where things are failing for me.

Also, usage of VFS on top of HttpClient seems broken right now, at  
least in
my environment/usage & on Gump, and the primary crash I found was in
HttpClient code. I can't be sure it isn't VFS (or even Ruper on top of  
VFS)
but the stack here seems to point to HttpClient (see below).

There seems to be no "test" here:
http://cvs.apache.org/builds/gump/2003-08-20/commons-httpclient.html
The target "test:" here seems blank:
http://cvs.apache.org/builds/gump/2003-08-20/commons-vfs.html
As such Ruper and above crash. Now, I ought put my unit (I guess
integration) tests into Ruper (I have some started,
http://cvs.apache.org/builds/gump/2003-08-20/krysalis-ruper-ant- 
test.html,
need 24 hours to get further) but I'd appreciate help from below. If  
at all
possible nightly gump runs of unit tests (specifically VFS on top of
HttpClient) would be greatly appreciated.


Exception in thread "main" java.lang.NullPointerException
at
org.apache.commons.httpclient.HttpMethodDirector.processRedire
ctResponse(Htt
pMethodDirect
or.java:454)
at
org.apache.commons.httpclient.HttpMethodDirector.isRetryNeeded
(HttpMethodDir
ector.java:63
9)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod
(HttpMethodDir
ector.java:14
5)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli
ent.java:378)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli
ent.java:268)
at
org.apache.commons.vfs.provider.http.HttpFileObject.doGetType(
HttpFileObject
.java:114)
at
org.apache.commons.vfs.provider.AbstractFileObject.attach(Abst
ractFileObject
.java:919)
at
org.apache.commons.vfs.provider.AbstractFileObject.exists(Abst
ractFileObject
.java:372)
at org.krysalis.ruper.util.VfsUtils.main(VfsUtils.java:413)
regards

Adam
- Original Message -
From: "Ortwin Glück" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Cc: "Commons HttpClient Project"  
<[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 9:31 AM
Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()


Adam,

I think HttpClient used to perform unit tests after compiling. However
this seems to have changed somehow? Still, be assured that the
HttpClient repository is usually (modulo checkin mistakes) in a state
where all tests succeed. All committers are told to run all unit test
before checking in.
Regards

Ortwin Glück

Adam R. B. Jack wrote:
5) Given all this, would it be possible for the two teams (VFS and
HttpClient) to add "test" projects to gump to augment the "compile"
projects? Meaning commons-httpclient-test and commons-vfs-test that
depend
upon their parents, and run unit tests. That way projects like
krysalis-ruper could chose to depend upon a successful unit test run,
and
not propagate crashes.
--
  _
  NOSE applied intelligence ag
  ortwin glück  [www]  http://www.nose.ch
  software engineer [email] [EMAIL PROTECTED]
  hardturmstrasse 171   [pgp key]  0x81CF3416
  8005 zurich   [office]  +41-1-277 57 35
  switzerland   [fax] +41-1-277 57 12
-
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()

[Adam R. B. Jack]

Thanks for that information, some project have separate test suite projects,
so I wondered. If it could be replace that'd be great 'cos I'd like to see
tests succeed on Gump (on latest stack below) not only on developers
machines. It is Gump where things are failing for me.

Also, usage of VFS on top of HttpClient seems broken right now, at least in
my environment/usage & on Gump, and the primary crash I found was in
HttpClient code. I can't be sure it isn't VFS (or even Ruper on top of VFS)
but the stack here seems to point to HttpClient (see below).

There seems to be no "test" here:
http://cvs.apache.org/builds/gump/2003-08-20/commons-httpclient.html
The target "test:" here seems blank:
http://cvs.apache.org/builds/gump/2003-08-20/commons-vfs.html

As such Ruper and above crash. Now, I ought put my unit (I guess
integration) tests into Ruper (I have some started,
http://cvs.apache.org/builds/gump/2003-08-20/krysalis-ruper-ant-test.html,
need 24 hours to get further) but I'd appreciate help from below. If at all
possible nightly gump runs of unit tests (specifically VFS on top of
HttpClient) would be greatly appreciated.


> > Exception in thread "main" java.lang.NullPointerException
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.processRedire
> > ctResponse(Htt
> > pMethodDirect
> > or.java:454)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.isRetryNeeded
> > (HttpMethodDir
> > ector.java:63
> > 9)
> > at
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod
> > (HttpMethodDir
> > ector.java:14
> > 5)
> > at
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli
> > ent.java:378)
> > at
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli
> > ent.java:268)
> > at
> > org.apache.commons.vfs.provider.http.HttpFileObject.doGetType(
> > HttpFileObject
> > .java:114)
> > at
> > org.apache.commons.vfs.provider.AbstractFileObject.attach(Abst
> > ractFileObject
> > .java:919)
> > at
> > org.apache.commons.vfs.provider.AbstractFileObject.exists(Abst
> > ractFileObject
> > .java:372)
> > at org.krysalis.ruper.util.VfsUtils.main(VfsUtils.java:413)
> >

regards

Adam
----- Original Message - 
From: "Ortwin Glück" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Cc: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 9:31 AM
Subject: Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()


> Adam,
>
> I think HttpClient used to perform unit tests after compiling. However
> this seems to have changed somehow? Still, be assured that the
> HttpClient repository is usually (modulo checkin mistakes) in a state
> where all tests succeed. All committers are told to run all unit test
> before checking in.
>
> Regards
>
> Ortwin Glück
>
> Adam R. B. Jack wrote:
> > 5) Given all this, would it be possible for the two teams (VFS and
> > HttpClient) to add "test" projects to gump to augment the "compile"
> > projects? Meaning commons-httpclient-test and commons-vfs-test that
depend
> > upon their parents, and run unit tests. That way projects like
> > krysalis-ruper could chose to depend upon a successful unit test run,
and
> > not propagate crashes.
>
> -- 
>   _
>   NOSE applied intelligence ag
>
>   ortwin glück  [www]  http://www.nose.ch
>   software engineer [email] [EMAIL PROTECTED]
>   hardturmstrasse 171   [pgp key]  0x81CF3416
>   8005 zurich   [office]  +41-1-277 57 35
>   switzerland   [fax] +41-1-277 57 12
>
>
> -
> 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()

[Ortwin Glück]

Adam,

I think HttpClient used to perform unit tests after compiling. However 
this seems to have changed somehow? Still, be assured that the 
HttpClient repository is usually (modulo checkin mistakes) in a state 
where all tests succeed. All committers are told to run all unit test 
before checking in.

Regards

Ortwin Glück

Adam R. B. Jack wrote:
5) Given all this, would it be possible for the two teams (VFS and
HttpClient) to add "test" projects to gump to augment the "compile"
projects? Meaning commons-httpclient-test and commons-vfs-test that depend
upon their parents, and run unit tests. That way projects like
krysalis-ruper could chose to depend upon a successful unit test run, and
not propagate crashes.
--
 _
 NOSE applied intelligence ag
 ortwin glück  [www]  http://www.nose.ch
 software engineer [email] [EMAIL PROTECTED]
 hardturmstrasse 171   [pgp key]  0x81CF3416
 8005 zurich   [office]  +41-1-277 57 35
 switzerland   [fax] +41-1-277 57 12
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]