Hi, We use Apache FTP Server embedded in an application (to allow some devices to download firmware updates). This is some issues I met.
1a. User manager properties file ================================ We would like this application let less files as possible on the user computer. Or at least, only files whose names are prefixed by the application name. The current version of our application uses an old code base of Apache FTP Server. Through a properties-based configuration, it sets "config.user-manager.prop-file" and "config.ip-restrictor.file" properties to use appropriate file names, in the current directory rather than in "./res". With this configuration, we create a ConfigurableFtpServerContext object, then the FtpServer object. And it works well. For a future version of our application, we would like to keep synchronized on Apache FTP Server trunk (at least until 1.0 version :-) ). So I wrote a Spring configuration file to get the same behavior: <file-user-manager file="./EquipmentSetup-ftp-users.properties" encrypt-passwords="true" /> The problem is that the configure() and createDefaultUsers() of the PropertiesUserManager object are called (by DefaultFtpServerContext constructor) *before* Spring sets the "file" value, so the "res" directory is still created, with a "user.gen" file whose content is irrelevant for our application. Thus, I would like to know if there is a way, using Spring, to bypass this behavior. Just in case, I tried to use a <user-manager><beans:bean class="org.apache.ftpserver.usermanager.PropertiesUserManager"/></user-m anager> instead of <file-user-manager/>, but with the same result... 1b. Bug in PropertiesUserManager ================================ In the configure() method, userDataFile.getParentFile() can return null (eg. if file name is "toto.properties" rather than "./toto.properties"), which is not checked and can lead to a NullPointerException. A possible fix is to call userDataFile.getAbsoluteFile().getParentFile(). 1c. Volatile user manager ========================= Use an appropriate name for the users properties file is acceptable for me, but the best would be to have no file at all. Our application creates and destroys FTP users on the fly, and all users are always destroyed when the application exits. So we have no real need for such a file, and we would like to avoid writing it. A solution would be to split PropertiesUserManager onto 2 classes: - a super-class which owns the BaseProperties object, implements user management and authentication, - a sub-class which handles the storage of the properties file. Another solution would be to allow the userDataFile attribute of PropertiesUserManager to take null value, which would mean that storage is disabled. What is your opinion on that? I can send a patch but maybe you have some projects for this class... 2. ftpserver-1.0.xsd ==================== In order to override several FTP commands, I had to modify the XSD schema. In its current form, the <commands> element allow only one <command> child (all the examples I found override only one FTP command ;-) ). I had to replace <xs:element name="command"> By <xs:element name="command" minOccurs="0" maxOccurs="unbounded"> 3. Project home page ==================== Is http://mina.apache.org/ftpserver/ the official home page for Apache FTP Server? http://mina.apache.org/ftpserver.html seems to be deprecated, but it is always present, and probably more known than the good one: it comes in first position in Google when you search for "Apache FTP Server". The old http://incubator.apache.org/ftpserver/ home page (still linked, eg. from http://www.slf4j.org/) also redirects to this page. Is it normal? Do you want to keep the more accurate page secret until the release of Apache FTP Server 1.0? :-) Thanks, Olivier
