|
[
Permlink
| « Hide
]
Kevin Wilson added a comment - 28/Dec/05 05:30 AM
Hold on, I think I have proxy issue that is screwin' stuff up.
Ok,
I have verified all proxies are bypassed. In issuing the raw FTPClient.list() command results in 2 codes being returned. a) from our local ftp server I get CODE 425 And no files are returned by using listFiles() still. Ok, I can fetch a file off our ftp server but I still can't get a directory
listing to check to see if any files are there to download. function FTPClient.retrieveFile() doesn't download ZIP files without corrupting
them, I can download a text file without issue. Changing the FTPCLient.setFileTransferMode(mode) to binary before tranfer does not help. String[] FTPClient.listNames() works as expected. The cwd list of files and
directories are returned. There must be something wrong with the parser detection or the building of the FTPFile object that doesn't allow listFiles() to work properly. May have a problem that just might be the cause as to why listFiles() isn't
working. When attempting to use listFiles(path) to get a single file I get the following exception. (code I am using is at the end of this message) ***************************************************************************** public FTPFile checkFile(String sServerFile){ RegexFTPFileEntryParserImpl.java still has these import definitions but the ORO
package is not included in src or jar file. *********************************************************** VMSVersioningFTPEntryParser.java has the imports I mentioned as well.
ORO package is required for commons-net-ftp parsers to function. I did not find
that mentioned anywhere on http://jakarta.apache.org/commons/net/ stating the commons-net was originally developed by ORO, Inc. Also, netbeans did not bark at all when the library was added, shouldn't it have? You must have the ORO package for the parser functions to work. It would be nice
for the commons-net download page to state that the ORO package is a dependency. Zip files still download corrupted though. And so far FTPFile.isFile() is Whoa. Sorry it's taken so long to respond (I was out of town) but you are
combining three or four issues into one defect report and that's never a good idea. Please, in the future one bug report per defect. Now, let me try to help you. Re: the dependency on ORO: this has been published for years. It is listed on Re: corrupting zip files: I am guessing that this issue is the same as the one Based on that, I am closing the issue. Sorry but this page would be a better location to give a blurb about what else
is required to use the package (imo) ... I see your point, but I don't agree that this page is the right one either. For
one thing that page is not under the control of commons-net developers but under the control of the whole jakarta-commons system. I could imagine that a list of dependencies there might get unwieldy. At a bare minimum, though, I think this belongs at the very top of the FAQ, as Reopened because I've decided to accomodate the reporter's request to make the
oro dependency more obvious. Accomodated the desire for better documentation of the ORO dependency by
1) putting a question about it in the FAQ on the Wiki 2) wrapping the NoClassDefFoundError thrown in the parser creation process in a ParserInitializationException with a message explicitly indicating the need for jakarta-oro.jar to be on the classpath. Thanks, this should help immensely.
>2) wrapping the NoClassDefFoundError thrown in the parser creation process in a |
|||||||||||||||||||||||||||||||||||||||||||||||||||||