commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brekke, Jeff" <Jeff.Bre...@qg.com>
Subject RE: [patch] NetComponents - FTPClient's restart functionality
Date Mon, 23 Sep 2002 13:15:01 GMT
No planned date as of yet, but we're attempting to get things in line for a
release.
I belive the following issues were raised the last time we attempted a vote
for 
release:

*) More tests
*) More committers
*) Status/Changes type document

Thanks!

=================================================================
Jeffrey D. Brekke                                   Quad/Graphics
Jeff.Brekke@qg.com                              http://www.qg.com


> -----Original Message-----
> From: Tapan Karecha [mailto:tapank@india.hp.com]
> Sent: Monday, September 23, 2002 8:02 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [patch] NetComponents - FTPClient's restart functionality
> 
> 
> 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:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message