You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2003/08/21 16:46:45 UTC
[VFS|HttpClient] Re: [VFS] Crashes in getContent()
A few more details/thoughts/questions:
1) The FSM appears to be using UrlFileObject although I have HttpClient in
my path. (This was when run from inside Eclipse and not command line, with
Eclipse project dependency upon HttpClient. With command line I get the
right one. Could this be some issue w/ a difference of class loading inside
Eclipse?)
Is there any way I can "get inside and dump/display" an FSM's providers?
(Unfortunately commons-logging seems to chose log4j in this environment not
jdk1.4 logging, and I don't have that configured, so I am loosing the
warnings.
2) I tested an "exists" call on a bad (non-existent) URL -- and it didn't
return "false" when used with the UrlFileObject. I've not figured out why,
but it seem like that problem has slipped back in. [If I can figure out
where to add it I'll submit a patch w/ a test for this.]
3) When I test on the command line, w/ latest HttpClient from CVS, I do get
a similar looking crash (see bottom) which looks like an HttpClient issue
(hence the shared subject.)
4) When I attempt to run all the unit tests for commons-vfs I get numerous
NullPtr crashes in the tests. Isthis somehow environmental, or are they
failing? The NullPtrs don't look like HttpClient only, so perhaps there are
two sets of problems.
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.
regards,
Adam
----------------------------------------------------------------------------
-----------------
F:\Krysalis\Testing>java org.krysalis.ruper.util.VfsUtils
Aug 21, 2003 8:24:09 AM
org.apache.commons.vfs.impl.StandardFileSystemManager addProvider
WARNING: Skipping provider
"org.apache.commons.vfs.provider.ftp.FtpFileProvider" because required cl
ass "org.apache.commons.net.ftp.FTPFile" is not available.
Aug 21, 2003 8:24:09 AM
org.apache.commons.vfs.impl.StandardFileSystemManager addProvider
WARNING: Skipping provider
"org.apache.commons.vfs.provider.smb.SmbFileProvider" because required cl
ass "jcifs.smb.SmbFile" is not available.
Aug 21, 2003 8:24:09 AM
org.apache.commons.vfs.impl.StandardFileSystemManager addProvider
WARNING: Skipping provider
"org.apache.commons.vfs.provider.webdav.WebdavFileProvider" because requi
red class "org.apache.webdav.lib.WebdavResource" is not available.
Aug 21, 2003 8:24:09 AM
org.apache.commons.vfs.impl.StandardFileSystemManager addProvider
WARNING: Skipping provider
"org.apache.commons.vfs.provider.sftp.SftpFileProvider" because required
class "com.jcraft.jsch.JSch" is not available.
Exception in thread "main" java.lang.NullPointerException
at
org.apache.commons.httpclient.HttpMethodDirector.processRedirectResponse(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(HttpClient.java:378)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:268)
at
org.apache.commons.vfs.provider.http.HttpFileObject.doGetType(HttpFileObject
.java:114)
at
org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject
.java:919)
at
org.apache.commons.vfs.provider.AbstractFileObject.exists(AbstractFileObject
.java:372)
at org.krysalis.ruper.util.VfsUtils.main(VfsUtils.java:413)
regards
Adam
Re: Is Bugzilla mail broken? was [VFS|HttpClient] Re: [VFS]
Crashes in getContent()
Posted by Oleg Kalnichevski <ol...@apache.org>.
It does seem to be broken. We might need to drop a line at
mvdb@apache.org or infrastructure@apache.org. 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Is Bugzilla mail broken? was [VFS|HttpClient] Re: [VFS] Crashes
in getContent()
Posted by Michael Becke <be...@u.washington.edu>.
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by Michael Becke <be...@u.washington.edu>.
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.
>>
>><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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by Michael Becke <be...@u.washington.edu>.
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.
<http://issues.apache.org/bugzilla/show_bug.cgi?id=22800>
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by Oleg Kalnichevski <ol...@apache.org>.
> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
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
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
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
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by Michael Becke <be...@u.washington.edu>.
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" <or...@nose.ch>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Cc: "Commons HttpClient Project"
> <co...@jakarta.apache.org>
> 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] ortwin.glueck@nose.ch
>> hardturmstrasse 171 [pgp key] 0x81CF3416
>> 8005 zurich [office] +41-1-277 57 35
>> switzerland [fax] +41-1-277 57 12
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by Michael Becke <be...@u.washington.edu>.
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" <or...@nose.ch>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Cc: "Commons HttpClient Project"
> <co...@jakarta.apache.org>
> 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] ortwin.glueck@nose.ch
>> hardturmstrasse 171 [pgp key] 0x81CF3416
>> 8005 zurich [office] +41-1-277 57 35
>> switzerland [fax] +41-1-277 57 12
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
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" <or...@nose.ch>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: "Commons HttpClient Project" <co...@jakarta.apache.org>
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] ortwin.glueck@nose.ch
> hardturmstrasse 171 [pgp key] 0x81CF3416
> 8005 zurich [office] +41-1-277 57 35
> switzerland [fax] +41-1-277 57 12
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
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" <or...@nose.ch>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: "Commons HttpClient Project" <co...@jakarta.apache.org>
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] ortwin.glueck@nose.ch
> hardturmstrasse 171 [pgp key] 0x81CF3416
> 8005 zurich [office] +41-1-277 57 35
> switzerland [fax] +41-1-277 57 12
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by Ortwin Glück <or...@nose.ch>.
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] ortwin.glueck@nose.ch
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Posted by Ortwin Glück <or...@nose.ch>.
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] ortwin.glueck@nose.ch
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12