You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tapan Karecha <ta...@india.hp.com> on 2002/09/20 12:45:23 UTC
[patch] NetComponents - FTPClient's restart functionality
This is a patch to fix the restart functionality in FTPClient. Following is
the summary of changes:
- Added a setter method "public void setRestartOffset(long)". This method
should be called every time (if restart is required) before a file retrieve
method is called. After the file is retrieved, the restart offset is set to
0. If this method is not called, the retrieve begins at the start of file.
- Added getter method "public long getRestartOffset()" that returns the
value of restart offset.
- Changed signature of restart(long) so that it is now private. This is
internally called from __openDataConnection(int command, String arg) if the
method setRestartOffset(long) was called with a positive long value.
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?
Also, can you suggest how can this be unit tested so that I can write a test
and send it?
- Tapan.
==== diff patch ====
--- FTPClient.java.orig Fri Sep 20 14:44:53 2002
+++ FTPClient.java Fri Sep 20 14:44:51 2002
@@ -246,6 +246,7 @@
private int __fileType, __fileFormat, __fileStructure,
__fileTransferMode;
private boolean __remoteVerificationEnabled;
private FTPFileListParser __fileListParser;
+ private long __restartOffset;
/***
* Default FTPClient constructor. Creates a new FTPClient instance
@@ -357,6 +358,12 @@
server.close();
return null;
}
+
+ if ((__restartOffset > 0) && !restart(__restartOffset))
+ {
+ server.close();
+ return null;
+ }
if (!FTPReply.isPositivePreliminary(sendCommand(command, arg)))
{
@@ -1548,11 +1555,38 @@
* @exception IOException If an I/O error occurs while either sending
a
* command to the server or receiving a reply from the server.
***/
- public boolean restart(long offset) throws IOException
+ private boolean restart(long offset) throws IOException
{
+ __restartOffset = 0;
return
FTPReply.isPositiveIntermediate(rest(Long.toString(offset)));
}
+ /***
+ * Sets the restart offset. The restart command is sent to the server
+ * only before sending the file transfer command. When this is done,
+ * the restart marker is reset
+ * <p>
+ * @param offset The offset into the remote file at which to start the
+ * next file transfer.
+ ***/
+ public void setRestartOffset(long offset)
+ {
+ if (offset > 0)
+ __restartOffset = offset;
+ }
+
+ /***
+ * Fetches the restart offset.
+ * <p>
+ * @return offset The offset into the remote file at which to start
the
+ * next file transfer.
+ ***/
+ public long getRestartOffset()
+ {
+ return __restartOffset;
+ }
+
+
/***
* Renames a remote file.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [patch] NetComponents - FTPClient's restart functionality
Posted by Tapan Karecha <ta...@india.hp.com>.
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 [mailto:dfs@savarese.org]
> Sent: Friday, September 20, 2002 8:32 PM
> To: commons-dev@jakarta.apache.org
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [patch] NetComponents - FTPClient's restart functionality
Posted by "Daniel F. Savarese" <df...@savarese.org>.
>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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>