Sorry, I do not have JUnit setup yet to run the test cases. But I hope the errors you have seen are related to the ListFormatter test cases where the new method added to the FtpFile was not implemented. I added that method to the test classes and checked those in. I simply returned a string "/short" from the getPhysicalFile method in these classes. I was not sure what else to return. Hope that takes care of it.
Regarding the addition of getPhysicalFileAsString method to the FtpFile, I think we should enforce the implementation classes to do it so generic Ftplets such as a logging Ftplet can be sure of getting a valid value instead of getting a pointer back in case an Ftplet returns a physical file with no toString() implemented. Regards, Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Mon, Apr 13, 2009 at 1:48 PM, Niklas Gustavsson <[email protected]>wrote: > On Mon, Apr 13, 2009 at 8:38 PM, Sai Pullabhotla > <[email protected]> wrote: > > Okay, I just checked in all my changes to the trunk for > review/test/further > > enhancements. > > Seems like the test broke, can you have a look at it? > > > Below are a few questions: > > > 1. Do we want to always send a specific type of reply from a specific > > command? In other words, do we want a command (e.g. RETR) to send a > generic > > FtpReply in some cases and DataTransferFtpReply in some cases? There is > > currently once place in the data transfer commands (STOR, RETR etc) where > > I'm sending a DefaultFtpReply. Perhaps we should change it to send > > DataTransferFtpReply? > > I don't care particulary if a command return different types of > replies. The user of the replies should always check the type before > using. > > > 3. Do we want to add a new method to the FtpFile interface that returns > the > > physical path of the file as a String? I recommend that we do this, but > > would like to know what you guys think. > > The use case for this would be for auditing purposes as you described > earlier? I would say that getPhysicalFile().toString() should suffice. > > /niklas >
