commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tapan Karecha" <>
Subject RE: [patch] NetComponents - FTPClient's restart functionality
Date Mon, 23 Sep 2002 13:02:04 GMT
Thanks Daniel! Also, the document Jeff points to (for unit testing protocol
stuff) has information that I can use to come up with the unit tests we want
for this feature. Will get back to you when I have something concrete to
contribute in this direction.

When is the first Jakarta release planned? I hope I am not repeating an
oft-asked question!

- Tapan.

> -----Original Message-----
> From: Daniel F. Savarese []
> Sent: Friday, September 20, 2002 8:32 PM
> To:
> Subject: Re: [patch] NetComponents - FTPClient's restart functionality
> >This is a patch to fix the restart functionality in
> FTPClient. Following is
> >the summary of changes:
> Thanks!  I for some reason thought we had applied this when you first
> brought it up, but I guess not.  I applied it with one minor change.
> I allowed the offset to be reset to zero.  You might need to do this
> when writing an interactive client and the user changes his
> mind before
> initiating the transfer.
> >A couple of lines in the diff may wrap onto the next line.
> If this is a
> >problem in applying this patch, how should I upload the patch file to
> >someplace from where it can be picked up by you?
> I wound up fixing the linewraps by hand so the patch would take.  In
> the future, if you include the patch as a MIME attachment rather than
> inserting it into your email, it should avoid the line wrapping.  But
> maybe we'll have voted you in as a committer by then :)
> >Also, can you suggest how can this be unit tested so that I
> can write a test
> >and send it?
> Testing any of the protocols is tough.  One way is to provide a fake
> server that reproduces the proper state transitions for each RFC.
> This is easy to do by using setSocketFactory() to set a factory on
> each client that produces a socket that creates input and output
> streams to this state transition engine.  However, once you go to
> all of that trouble, you might as well write a bunch of full blown
> servers.  Therefore, it is best to test against some set of servers
> that the developer trusts to be reasonably faithful implementations
> of the RFC.  These could be set in a property file and default to
> test servers on the developers machine.  So a restart unit test would
> involve ftp'ing a known file, reading some random number of bytes
> from it, closing the data connection, and then opening a new data
> connection, restarting from the end of the local file.  After the
> transfer is complete, do a binary byte-for-byte comparison of each
> file.  But we ought to create some skeleton code or a base testing
> class(es) that can be used as starting points for writing these
> protocol tests.  It may not be a bad idea to look at what HttpClient
> does.
> Jeff, I was in the habit of maintaining a CHANGES file that recorded
> all of the major changes between each version of the software.
> Autogenerated changelogs tend to get cluttered with a lot of
> extraneous
> stuff.  What's the equivalent place to store this
> information?  I don't
> want to reconstitute the changes from memory when people start asking
> what changed between v1.3.8 and the first Jakarta release.
> thanks,
> daniel
> --
> To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message