commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [patch] NetComponents - FTPClient's restart functionality
Date Fri, 20 Sep 2002 15:02:10 GMT

>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

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.


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

View raw message