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]