Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
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()
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 project name=commons-httpclient .. depend 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 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 project
name=commons-httpclient .. depend
name=commons-httpclient-old-stable-branch inherit=all) or rename
projects in order to manage it for folk? It seems better for the active
project to manage this once (with sub-projects having named projects should
they chose) than for sub-projects to attempt to keep track.
If not, it gets into me as a user having to manage VFS ('cos they are too
busy off elsewhere to do such things) and that seems (1) rude [I oughtn't]
(2) messy we'd loose valuable gump runs due to folks trying to keep in
synch.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
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. http://issues.apache.org/bugzilla/show_bug.cgi?id=22800 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()
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()
-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 PROTECTED] - To unsubscribe, e-mail: [EMAIL
RE: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
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()
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()
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()
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()
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.29content-type=text/vnd.viewcvs-markup se module tag=.. http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi3.xml?rev=1.4content-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()
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()
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()
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()
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]
