On Mon, Jan 26, 2009 at 10:26 PM, West, John C <John.C.West@citizensbank.com> wrote: > > I've been using Apache FtpServer for a couple years now to handle some > automated internal file tranfers that involve some post-processing and > it's been excellent - reliable and fast. Also, FtpServer has now graduated from Incubator and is part of the Apache MINA project. Your questions would be better served by going there; dev@mina.apache.org Cheers Niclas -- http://www.qi4j.org - New Energy for Java
On Mon, Jan 26, 2009 at 10:26 PM, West, John C <John.C.West@citizensbank.com> wrote: > I have a keystore (conf/keystore.jks) with one certificate: > % keytool -list -keystore conf/keystore.jks > Enter keystore password: password > > Keystore type: jks > Keystore provider: IBMJCE > > Your keystore contains 1 entry > > xfer, Jan 26, 2009, trustedCertEntry, > Certificate fingerprint (MD5): > 80:40:2D:97:25:20:AD:50:BE:9D:06:CA:B0:77:CA:EB This is not sufficient, you need to have at least a key for the server to use. You can generate this using keytool -genkey. > My ftpd.xml has the following configuration: > > <listeners> > <nio-listener name="default" port="30021" > implicit-ssl="true"> > <ssl protocol="SSL" > client-authentication="WANT"> Noramlly, you do not need these attributes. > <keystore file="conf/keystore.jks" > password="password" key-alias="xfer" algorithm="IbmX509" /> You do not need the key-alias attribute if the keystore only contains your key. I'm not sure if you need the algorithm, but I would not think so. > <truststore file="conf/keystore.jks" > password="password" algorithm="IbmX509" /> Again, algorithm might not be needed. That should be it, let us know if it helps or not. We can probably improve our error logging in this area, I'll have a look at that after 1.0. /niklas
I've been using Apache FtpServer for a couple years now to handle some
automated internal file tranfers that involve some post-processing and
it's been excellent - reliable and fast. However, I have a new
requirement that the connection be SSL. I thought it would be quick and
easy to configure, despite the fact that I know absolutely nothing about
how this should be configured.
After setting it up that way I thought it should be, I get this in the
logs when the client tries to connect:
[ WARN] 2009-01-26 16:04:54,543 [] [10.2.56.43] CREATED
[ WARN] 2009-01-26 16:04:54,544 [] [10.2.56.43] OPENED
(Log level is set to DEBUG)
It never progresses past that stage. The client is never prompted for a
username. I've tried several things, but essentially my attempts are
random since I don't really know what I'm doing. So, I'd appreciate it
if someone could offer some advice.
I have a keystore (conf/keystore.jks) with one certificate:
% keytool -list -keystore conf/keystore.jks
Enter keystore password: password
Keystore type: jks
Keystore provider: IBMJCE
Your keystore contains 1 entry
xfer, Jan 26, 2009, trustedCertEntry,
Certificate fingerprint (MD5):
80:40:2D:97:25:20:AD:50:BE:9D:06:CA:B0:77:CA:EB
This is running on AIX. My contact on the client side tells me it should
be enough to just have the certificate (it was provided by him and is
the same as the one in his application).
My ftpd.xml has the following configuration:
<listeners>
<nio-listener name="default" port="30021"
implicit-ssl="true">
<ssl protocol="SSL"
client-authentication="WANT">
<keystore file="conf/keystore.jks"
password="password" key-alias="xfer" algorithm="IbmX509" />
<truststore file="conf/keystore.jks"
password="password" algorithm="IbmX509" />
</ssl>
<data-connection implicit-ssl="true"/>
</nio-listener>
</listeners>
My last desperate attempt to get this working was to add 'protocol="SSL"
client-authentication="WANT"' to ssl and to add the '<data-connection
implicit-ssl="true"/>' line. Neither change got me past the 'OPENED'
step. I don't get any further that that when I try locally, so I know it
isn't a network issue. The server finds the keystore when it starts up.
There are no exceptions in the log, except for the one caused by forcing
the connection to close.
Can anyone help me out? The attached logfile is a clean start,
connection attempt, cancelled from the client, shutdown.
Thanks in advance!
-----------------------------------------
Use of email is inherently insecure. Confidential information,
including account information, and personally identifiable
information, should not be transmitted via email, or email
attachment. In no event shall Citizens or any of its affiliates
accept any responsibility for the loss, use or misuse of any
information including confidential information, which is sent to
Citizens or its affiliates via email, or email attachment. Citizens
does not guarantee the accuracy of any email or email attachment,
that an email will be received by Citizens or that Citizens will
respond to any email.
This email message is confidential and/or privileged. It is to be
used by the intended recipient only. Use of the information
contained in this email by anyone other than the intended recipient
is strictly prohibited. If you have received this message in error,
please notify the sender immediately and promptly destroy any
record of this email.
On Mon, Nov 17, 2008 at 9:07 PM, Niklas Gustavsson <niklas@protocol7.com> wrote: > On Mon, Nov 17, 2008 at 1:11 PM, Eduardo Luque <eluque@aplicatec.com> wrote: >> The problem is when I try to upload a large file, the connection between >> client and server closes after several minutes without any message of >> error > > This is a known bug where we did not update the idle counter during > data transfers. You can either increase the idle-timeout value to a > big value or use trunk (or the upcoming M4). Also remember to point out that FtpServer is now part of the Apache MINA project, and this list should be non-active now. Cheers Niclas
On Mon, Nov 17, 2008 at 1:11 PM, Eduardo Luque <eluque@aplicatec.com> wrote: > The problem is when I try to upload a large file, the connection between > client and server closes after several minutes without any message of > error This is a known bug where we did not update the idle counter during data transfers. You can either increase the idle-timeout value to a big value or use trunk (or the upcoming M4). /niklas
I have embedded the apache ftp server into my java application. My
configuration file ftpd.xml is :
<server xmlns="http://mina.apache.org/ftpserver/spring/v1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://mina.apache.org/ftpserver/spring/v1
http://mina.apache.org/ftpserver/ftpserver-1.0.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"
id="server"
max-logins="700"
anon-enabled="false"
max-anon-logins="123"
max-login-failures="124"
login-failure-delay="125">
<listeners>
<nio-listener name="default" port="21" implicit-ssl="false"
idle-timeout="60" local-address="the ip">
<data-connection idle-timeout="30000">
<active enabled="false" local-address="the ip"
local-port="2323" ip-check="true"/>
<passive ports="60000-60535" address="the ip"
external-address="the ip" />
</data-connection>
</nio-listener>
</listeners>
<ftplets>
<ftplet name="AlarmFtpUploaded">
<beans:bean
class="com.aplicatec.mwengine.alarmserver.alarmserverlet.alarmftp.AlarmFtpUploaded">
</beans:bean>
</ftplet>
</ftplets>
<file-user-manager file="/etc/mwengine/alarmserver/users.properties"
encrypt-passwords="false" />
</server>
The problem is when I try to upload a large file, the connection between
client and server closes after several minutes without any message of
error
It is problem of configuration?? I use passive mode to connect. Could
someone help me? Thanks
Dave Roberts wrote: > Niklas, what happened to the SVN information prior to the move? The > historical log information appears to be intact, but it's not > possible to get revisions of code from before the move. Either > that, or I'm unable to drive the SVN client properly. :) And as is the tradition for computer world - as soon as I hit the Send button, I work out how to do it (sort of). Emailing to the world is like a self-therapy. It's weird, in Eclipse's plug-in, if I choose to create a revision link, it will only offer the revisions going back to the 12th Jan. However, going into Export shows all revisions!
On Thu, Feb 21, 2008 at 5:26 PM, Dave Roberts <dave.roberts@saaconsultants.com> wrote: > Niklas Gustavsson wrote: > > SVN has now been moved to the MINA sandbox. That means you now find it here: > > https://svn.apache.org/repos/asf/mina/sandbox/ftpserver > > Niklas, what happened to the SVN information prior to the move? The > historical log information appears to be intact, but it's not > possible to get revisions of code from before the move. Either > that, or I'm unable to drive the SVN client properly. :) The FtpServer part of SVN was moved, so you will find all history preserved at: http://svn.apache.org/repos/asf/mina/sandbox/ftpserver/ We will likely move out of the sandbox at MINA into a top level directory, but the exact structure is not yet determined. If you get a working copy checked out, you can svn switch to update it to the new location. > > Also, this means that those of you which subscribe to the FtpServer > > commit list can unsubscribe as no more commits will be sent there. > > Instead, sign up for the MINA commit list. > > What's the policy for using the new mailing list? There's a high > volume of traffic on there, all of which seems to be about MINA. Is > there a means of subscribing to the FTPServer only information? Or > would we have to set our mail filters up to tweak the incoming > stream of mails? Yes, this is a problem we discussed during the move. The reason for choosing a shared developer list is that we want MINA developers to participate in discussions on FtpServer and the other way around. Now, this will cause an issue for those who want to participate in FtpServer development but doesn't care to much about MINA (you should :-). We will try to use a [ftpserver] prefix on threads concerning FtpServer which should help setting up filters, but I can of course not guarantee that it will be used on all threads. For those who are users of FtpServer or want to participate by feature requests or bugs, there is the new users list. I hope this works for you, if not, please feel free to suggest how to improve this, we're just getting started. /niklas
Niklas Gustavsson wrote: > SVN has now been moved to the MINA sandbox. That means you now find it here: > https://svn.apache.org/repos/asf/mina/sandbox/ftpserver Niklas, what happened to the SVN information prior to the move? The historical log information appears to be intact, but it's not possible to get revisions of code from before the move. Either that, or I'm unable to drive the SVN client properly. :) > Also, this means that those of you which subscribe to the FtpServer > commit list can unsubscribe as no more commits will be sent there. > Instead, sign up for the MINA commit list. What's the policy for using the new mailing list? There's a high volume of traffic on there, all of which seems to be about MINA. Is there a means of subscribing to the FTPServer only information? Or would we have to set our mail filters up to tweak the incoming stream of mails?
Could you please send the debug level log of the server?
/niklas
On Wed, Feb 13, 2008 at 3:15 PM, Janardhanan, Ajith (AJANARDH)
<AJANARDH@arinc.com> wrote:
> I am using the ftp command in windows and solaris as the client. The log
> file is attached for the ls -l command from the ftp terminal. While
> debugging, the found that the command sent is NLST -l, which in turn
> lists the directory in the NLIST_FORMAT correctly, but the '-l'
> parameter is somehow translated as the remote directory parameter.
> I built the apache ftp server code taken from the 1.4 branch in Nov
> 2007. The result is the same even without my tweaked code. ie; with the
> plain apache ftpserver code, an ls -l gives the same result.
>
>
> Thanks
> Ajith
>
>
>
>
>
>
>
> -----Original Message-----
> From: protocol7@gmail.com [mailto:protocol7@gmail.com] On Behalf Of
> Niklas Gustavsson
> Sent: Wednesday, February 13, 2008 7:10 AM
> To: ftpserver-dev@incubator.apache.org
> Subject: Re: problem with DataConnection.transferToClient(outputStr);
>
> What client are you using for testing? Can you repeat this behavior with
> any client? Could you provide the deb level log from the server?
>
> /niklas
>
> On Feb 11, 2008 10:41 PM, Janardhanan, Ajith (AJANARDH)
> <AJANARDH@arinc.com> wrote:
> > I have the Apache ftp server embedded in my code and tweaked the code
> > to add a new onListStart() command. In the onListStart(), when the
> > user does an 'ls -l' command, I display a list, without actually going
>
> > in to the filesystem:
> >
> > eg:
> >
> > ftp> ls -l
> > 200 PORT command successful
> > 150 Opening ASCII mode data connection for file list.
> > 200 PORT command successful
> > 150 Opening ASCII mode data connection for file list.
> > -rw-r--r-- 1 ajith ftpctrl 128000 Feb 05 16:55
> > fileDOJ7gd.1202230507
> > -rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
> > filenmfTNr.1202394783
> > 226 Transfer Complete
> > remote: incoming
> > 1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
> > 226 Transfer Complete
> > remote: -l
> > 1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
> >
> >
> >
> > In my code, this is what I am doing:
> >
> > public FtpletEnum onDirStart(FtpSession session, FtpRequest request,
> > FtpReplyOutput response)
> > {
> > String outputStr = "-rw-r--r-- 1 ajith ftpctrl 128000 Feb 05
> 16:55
> > fileDOJ7gd.1202230507\n
> > -rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
> > filenmfTNr.1202394783\n";
> >
> > DataConnection dataConnection =null;
> > response.write(new DefaultFtpReply(150, "Opening ASCII mode data
> > connection for file list.")); dataConnection =
> > session.getDataConnection().openConnection();
> > dataConnection.transferToClient(outputStr);
> > response.write(new DefaultFtpReply(226, "Transfer Complete")); }
> >
> >
> > Any idea who puts in the remote: -l line, I want to get rid of the
> > line in the user terminal.
> >
> > Any help appreciated
> >
> > Thanks
> > Ajith
> >
>
Hey
That 421 looks like it's coming from your client ("remote server" is
what gives it away). FtpServer does not send such a message at any
time.
/niklas
On Wed, Feb 13, 2008 at 7:22 PM, Janardhanan, Ajith (AJANARDH)
<AJANARDH@arinc.com> wrote:
> When the idle time out is reached, in stead of the standard "421 Service
> not available, remote server has closed connection" message spitted on
> to the client, I need to display a different message. Greately
> appreciate if any one could tell me how to do it.
>
> Currently my customized messages are in the FtpStatus.properties file,
> which is in the org.apache.ftpserver.message package. Looks like the
> above message is not pulled from this file.
>
> I am using the code from the 1.4 branch.
>
>
When the idle time out is reached, in stead of the standard "421 Service not available, remote server has closed connection" message spitted on to the client, I need to display a different message. Greately appreciate if any one could tell me how to do it. Currently my customized messages are in the FtpStatus.properties file, which is in the org.apache.ftpserver.message package. Looks like the above message is not pulled from this file. I am using the code from the 1.4 branch.
I am using the ftp command in windows and solaris as the client. The log
file is attached for the ls -l command from the ftp terminal. While
debugging, the found that the command sent is NLST -l, which in turn
lists the directory in the NLIST_FORMAT correctly, but the '-l'
parameter is somehow translated as the remote directory parameter.
I built the apache ftp server code taken from the 1.4 branch in Nov
2007. The result is the same even without my tweaked code. ie; with the
plain apache ftpserver code, an ls -l gives the same result.
Thanks
Ajith
-----Original Message-----
From: protocol7@gmail.com [mailto:protocol7@gmail.com] On Behalf Of
Niklas Gustavsson
Sent: Wednesday, February 13, 2008 7:10 AM
To: ftpserver-dev@incubator.apache.org
Subject: Re: problem with DataConnection.transferToClient(outputStr);
What client are you using for testing? Can you repeat this behavior with
any client? Could you provide the deb level log from the server?
/niklas
On Feb 11, 2008 10:41 PM, Janardhanan, Ajith (AJANARDH)
<AJANARDH@arinc.com> wrote:
> I have the Apache ftp server embedded in my code and tweaked the code
> to add a new onListStart() command. In the onListStart(), when the
> user does an 'ls -l' command, I display a list, without actually going
> in to the filesystem:
>
> eg:
>
> ftp> ls -l
> 200 PORT command successful
> 150 Opening ASCII mode data connection for file list.
> 200 PORT command successful
> 150 Opening ASCII mode data connection for file list.
> -rw-r--r-- 1 ajith ftpctrl 128000 Feb 05 16:55
> fileDOJ7gd.1202230507
> -rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
> filenmfTNr.1202394783
> 226 Transfer Complete
> remote: incoming
> 1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
> 226 Transfer Complete
> remote: -l
> 1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
>
>
>
> In my code, this is what I am doing:
>
> public FtpletEnum onDirStart(FtpSession session, FtpRequest request,
> FtpReplyOutput response)
> {
> String outputStr = "-rw-r--r-- 1 ajith ftpctrl 128000 Feb 05
16:55
> fileDOJ7gd.1202230507\n
> -rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
> filenmfTNr.1202394783\n";
>
> DataConnection dataConnection =null;
> response.write(new DefaultFtpReply(150, "Opening ASCII mode data
> connection for file list.")); dataConnection =
> session.getDataConnection().openConnection();
> dataConnection.transferToClient(outputStr);
> response.write(new DefaultFtpReply(226, "Transfer Complete")); }
>
>
> Any idea who puts in the remote: -l line, I want to get rid of the
> line in the user terminal.
>
> Any help appreciated
>
> Thanks
> Ajith
>
What client are you using for testing? Can you repeat this behavior
with any client? Could you provide the deb level log from the server?
/niklas
On Feb 11, 2008 10:41 PM, Janardhanan, Ajith (AJANARDH)
<AJANARDH@arinc.com> wrote:
> I have the Apache ftp server embedded in my code and tweaked the code to
> add a new onListStart() command. In the onListStart(), when the user
> does an 'ls -l' command, I display a list, without actually going in to
> the filesystem:
>
> eg:
>
> ftp> ls -l
> 200 PORT command successful
> 150 Opening ASCII mode data connection for file list.
> 200 PORT command successful
> 150 Opening ASCII mode data connection for file list.
> -rw-r--r-- 1 ajith ftpctrl 128000 Feb 05 16:55
> fileDOJ7gd.1202230507
> -rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
> filenmfTNr.1202394783
> 226 Transfer Complete
> remote: incoming
> 1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
> 226 Transfer Complete
> remote: -l
> 1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
>
>
>
> In my code, this is what I am doing:
>
> public FtpletEnum onDirStart(FtpSession session, FtpRequest request,
> FtpReplyOutput response)
> {
> String outputStr = "-rw-r--r-- 1 ajith ftpctrl 128000 Feb 05 16:55
> fileDOJ7gd.1202230507\n
> -rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
> filenmfTNr.1202394783\n";
>
> DataConnection dataConnection =null;
> response.write(new DefaultFtpReply(150, "Opening ASCII mode data
> connection for file list."));
> dataConnection = session.getDataConnection().openConnection();
> dataConnection.transferToClient(outputStr);
> response.write(new DefaultFtpReply(226, "Transfer Complete"));
> }
>
>
> Any idea who puts in the remote: -l line, I want to get rid of the line
> in the user terminal.
>
> Any help appreciated
>
> Thanks
> Ajith
>
I have the Apache ftp server embedded in my code and tweaked the code to
add a new onListStart() command. In the onListStart(), when the user
does an 'ls -l' command, I display a list, without actually going in to
the filesystem:
eg:
ftp> ls -l
200 PORT command successful
150 Opening ASCII mode data connection for file list.
200 PORT command successful
150 Opening ASCII mode data connection for file list.
-rw-r--r-- 1 ajith ftpctrl 128000 Feb 05 16:55
fileDOJ7gd.1202230507
-rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
filenmfTNr.1202394783
226 Transfer Complete
remote: incoming
1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
226 Transfer Complete
remote: -l
1125 bytes received in 0.026 seconds (42.82 Kbytes/s)
In my code, this is what I am doing:
public FtpletEnum onDirStart(FtpSession session, FtpRequest request,
FtpReplyOutput response)
{
String outputStr = "-rw-r--r-- 1 ajith ftpctrl 128000 Feb 05 16:55
fileDOJ7gd.1202230507\n
-rw-r--r-- 1 ajith ftpctrl 7982 Feb 07 14:33
filenmfTNr.1202394783\n";
DataConnection dataConnection =null;
response.write(new DefaultFtpReply(150, "Opening ASCII mode data
connection for file list."));
dataConnection = session.getDataConnection().openConnection();
dataConnection.transferToClient(outputStr);
response.write(new DefaultFtpReply(226, "Transfer Complete"));
}
Any idea who puts in the remote: -l line, I want to get rid of the line
in the user terminal.
Any help appreciated
Thanks
Ajith
Hi, answers inline On Feb 11, 2008 1:38 AM, Narahari 'n' Savitha <savithari@gmail.com> wrote: > Friends, > > I am embedding an ftp server in our code. I have used BaseUser to set user > configuration. I am unable to find docs where I can tell ftp server to > listen on > > a given hostname (ip has been given host name) This is part of the Listener configuration, see the documentation here: http://mina.apache.org/ftpserver-listeners.html Specifically, you want to take a look at: config.listeners.<listener name>.address config.listeners.<listener name>.port Note that this documentation is for the 1.4 branch of the code, trunk will get new configuration soon, along with updated documentation. > PS: I am presuming BaseUser.setHomeDirectory() to be used to determine > where to put the file. Yes, it will be the root directory for that user. /niklas
Friends, I am embedding an ftp server in our code. I have used BaseUser to set user configuration. I am unable to find docs where I can tell ftp server to listen on a given hostname (ip has been given host name) a given port say for example 5000 instead of the default 21. -Narahari PS: I am presuming BaseUser.setHomeDirectory() to be used to determine where to put the file.
Hey Earl, yes, you could create a DB backed file system implementation. In fact, if you're able to do it in open I would be happy to help you out and get the code into the core project. As for users, we already have DBUserManager which should let you do that. The project has graduated from incubation and is now a subproject to Apache MINA. As part of that, the mailing list has moved. I've added the new list on the recipients, please keep any further communication there. The project is active, albeit somewhat slow now as I'm very busy with other things (like moving) for the next couple of weeks. That being said, any contributions are welcomed. We do not have a list of compatible FTP clients, however, I would like FtpServer to be as compliant to the relevant RFC as possible and thus hopefully support as many clients as possible. Any problems in this area will be quickly handled if reported. /niklas On 2/5/08, Earl Cahill <cahille@yahoo.com> wrote: > Howdy, > > Let's say I want to have no mounted drives, and wanted to put all user information (username, passwords, quotas, etc.), file information (file names, directory name, owners, etc.) and actual files (bytes) from mysql. Would ftpserver allow me to do that? I see a bunch of hooks, but I haven't dived into the code. I am planning on starting that tonight. > > Also, what is that status of the project? Are there active contributors? What are the odds of it graduating from incubator status? > > Finally, is there a list of supported ftp clients? Being able to say my server will work with cuteftp, wsftp, fireftp, etc., would be great. > > Thanks, > Earl > > > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ >
Howdy,
Let's say I want to have no mounted drives, and wanted to put all user information (username,
passwords, quotas, etc.), file information (file names, directory name, owners, etc.) and
actual files (bytes) from mysql. Would ftpserver allow me to do that? I see a bunch of hooks,
but I haven't dived into the code. I am planning on starting that tonight.
Also, what is that status of the project? Are there active contributors? What are the odds
of it graduating from incubator status?
Finally, is there a list of supported ftp clients? Being able to say my server will work
with cuteftp, wsftp, fireftp, etc., would be great.
Thanks,
Earl
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
(Sorry if you get duplicates of this email, there has been some troubles with the moderation of this list so I'm not sure if this has already been delivered) Hi As part of the move to MINA, this mailing list is closing down. Instead, you will have to subscribe to one of the new mailing lists. For users who are not interested in our day to day development but rather like to ask and participate in usage related questions or request new features, a new list has been created: ftpserver-users@mina.apache.org. To subscribe, send an email to ftpserver-users-subscribe@mina.apache.org. If you would like to participate in our development, these discussion will now be held on the MINA developers list: dev@mina.apache.org. To subscribe, send an email to dev-subscribe@mina.apache.org. If you subscribe to this list on gmane or Nabble and would like to be on the users list, you need to take no action as both these sites have been updated. Also, the commit list is moving to the MINA commit list. To subscribe, send an email to commits-subscribe@mina.apache.org. /niklas
Hi As part of the move to MINA, this mailing list is closing down. Instead, you will have to subscribe to one of the new mailing lists. For users who are not interested in our day to day development but rather like to ask and participate in usage related questions or request new features, a new list has been created: ftpserver-users@mina.apache.org. To subscribe, send an email to ftpserver-users-subscribe@mina.apache.org. If you would like to participate in our development, these discussion will now be held on the MINA developers list: dev@mina.apache.org. To subscribe, send an email to dev-subscribe@mina.apache.org. If you subscribe to this list on gmane or Nabble and would like to be on the users list, you need to take no action as both these sites have been updated. Also, the commit list is moving to the MINA commit list. To subscribe, send an email to commits-subscribe@mina.apache.org. /niklas
Hi As part of the move to MINA, this mailing list is closing down. Instead, you will have to subscribe to one of the new mailing lists. For users who are not interested in our day to day development but rather like to ask and participate in usage related questions or request new features, a new list has been created: ftpserver-users@mina.apache.org. To subscribe, send an email to ftpserver-users-subscribe@mina.apache.org. If you would like to participate in our development, these discussion will now be held on the MINA developers list: dev@mina.apache.org. To subscribe, send an email to dev-subscribe@mina.apache.org. If you subscribe to this list on gmane or Nabble and would like to be on the users list, you need to take no action as both these sites have been updated. Also, the commit list is moving to the MINA commit list. To subscribe, send an email to commits-subscribe@mina.apache.org. /niklas
Niklas Gustavsson wrote: > I'm just beginning the move of our resource to MINA. As a first step, > I'm moving over our SVN. As soon as it's complete, I'll get back with > instructions on how to update your working copies. SVN has now been moved to the MINA sandbox. That means you now find it here: https://svn.apache.org/repos/asf/mina/sandbox/ftpserver If you got a working copy check out, either do an new checkout from the new URL or use the SVN switch command to update your current working copy. Also, this means that those of you which subscribe to the FtpServer commit list can unsubscribe as no more commits will be sent there. Instead, sign up for the MINA commit list. /niklas
Hi I'm just beginning the move of our resource to MINA. As a first step, I'm moving over our SVN. As soon as it's complete, I'll get back with instructions on how to update your working copies. /niklas
Congratulations! :) SY, Alexey 2007/12/18, Niclas Hedhman <niclas@hedhman.org>: > > Today is a good day. The FtpServer has graduated its lengthy ride in the > Incubator, and will continue its life under the auspices of the MINA PMC. > > Mina is the high-performant, non-blocking I/O layer that is under the hood in > FtpServer, and is a natural home. > > The FtpServer PPMC will need to coordinate the transfer of resources, such as > codebase, website, mailing lists and so forth, and we will keep the community > up-to-date of what is happening. > > > Cheers > -- > Niclas Hedhman, Software Developer > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug >
Today is a good day. The FtpServer has graduated its lengthy ride in the Incubator, and will continue its life under the auspices of the MINA PMC. Mina is the high-performant, non-blocking I/O layer that is under the hood in FtpServer, and is a natural home. The FtpServer PPMC will need to coordinate the transfer of resources, such as codebase, website, mailing lists and so forth, and we will keep the community up-to-date of what is happening. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
using the ftp server as a standalone server. How do I know when a file upload has finished? Compare to proftpd which uploades into .in.filename and only when the upload has completed the file is renamed to its correct name. I wouldn't like to have to write a Java hook to know this, i.e. I would very much like to continue using the server as an uncomplicated, easy to install, low requirements, fast, plain-vanilla standalone ftp server. Is the above feature already available via some parameter that I've missed? If not this would be my wish for a new feature. Lars
I have a an ftplet that needs to disconnect after 10 minutes of no
activity. I am calling the following method in my onConnect() method:
public FtpletEnum onLogin(FtpSession session, FtpRequest request,
FtpReplyOutput response)
throws FtpException, IOException
{
//set the max idle timeout
session.setMaxIdleTime(10);
return null;
}
However this does not seems working. Any idea where I am doing wrong?
Thanks
Ajith
Dave Roberts wrote: > 3) Create a 1.4 branch in Subversion. Keep the 1.4 branch as a > maintenance release where only bugs are fixed, and the TRUNK version > will move to Java 1.5, MINA 1.1.x and have all the new development. Since everyone so far has agreed on option 3, and no one has objected, I'll go ahead and make the changes. As I said before, I will continue accepting patches (bug fixes or improvements) for the 1.4 branch but won't be doing any active development myself. As part of this action, I will drop the IO listener from trunk and will restructure our code to fully make use of MINA. This will lead to a a period of destabilization. Hope you all okay with that, bug reports will of course be welcome :-) /niklas
I'm also agree to choose the option 3 --- Pierre Huttin pierre@huttin.com ECM/Documentum Consultant > -----Original Message----- > From: Dave Roberts [mailto:dave.roberts@saaconsultants.com] > Sent: Thursday, November 22, 2007 3:38 PM > To: ftpserver-dev@incubator.apache.org > Subject: Re: Java 1.4 and 1.5 > > Niklas Gustavsson wrote: > > That was excellent timing, I had a draft of pretty much the same email > > sitting waiting for completion tonight :-) > > That's great! I'm pleased you were thinking in the same direction also. > > >> 3) Create a 1.4 branch in Subversion. > > This gets my vote. > > Whether the branch is for bug fixes only or continues to get new > development is actually irrelevant and I should have left that part out.
Niklas Gustavsson wrote: > That was excellent timing, I had a draft of pretty much the same email > sitting waiting for completion tonight :-) That's great! I'm pleased you were thinking in the same direction also. >> 3) Create a 1.4 branch in Subversion. This gets my vote. Whether the branch is for bug fixes only or continues to get new development is actually irrelevant and I should have left that part out.
i vote for option (3) -----Ursprüngliche Nachricht----- Von: news [mailto:news@ger.gmane.org]Im Auftrag von Niklas Gustavsson Gesendet: Donnerstag, 22. November 2007 15:18 An: ftpserver-dev@incubator.apache.org Betreff: Re: Java 1.4 and 1.5 That was excellent timing, I had a draft of pretty much the same email sitting waiting for completion tonight :-) My vote is on 3 and I'm willing to continue apply patches for the 1.4 branch. But, I would like to drop 1.4 support for trunk since there are tons of places where we could remove our somewhat crappy code for much better patterns introduced by MINA. If we agree on this way forward, I will make the changes this weekend. /niklas Dave Roberts wrote: > We currently have the situation where the project builds and works > with either JVM, although 1.5 is required for the SSL tests. > > Due to the need for 1.4 compatibility, we're using the 1.0.x code > branch of MINA, the latest being 1.0.7. > > It's currently not possible to switch to the 1.1.x branch of MINA > without making some code changes, to make use of the > java.util.concurrent classes, rather than the ones provided in the > backport-util-concurrent JAR. > > Certainly for me this has now become a problem where I've needed to > change the FTP Server code to move forwards and make use of MINA > 1.1.4. Obviously this isn't a patch I can submit, as it will break > our Java 1.4 compatibility. > > We have 3 options:- > > 1) Keep the code as it is, and remain compatible with both Java 1.4 > and Java 1.5. > > 2) Drop Java 1.4, change the code to use MINA 1.1.x and remove the > dependency on backport-util-concurrent. > > 3) Create a 1.4 branch in Subversion. Keep the 1.4 branch as a > maintenance release where only bugs are fixed, and the TRUNK version > will move to Java 1.5, MINA 1.1.x and have all the new development. > > > > This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the recipient, for system management and security reasons. This access is controlled under Regulation of security reasons. This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises.
That was excellent timing, I had a draft of pretty much the same email sitting waiting for completion tonight :-) My vote is on 3 and I'm willing to continue apply patches for the 1.4 branch. But, I would like to drop 1.4 support for trunk since there are tons of places where we could remove our somewhat crappy code for much better patterns introduced by MINA. If we agree on this way forward, I will make the changes this weekend. /niklas Dave Roberts wrote: > We currently have the situation where the project builds and works > with either JVM, although 1.5 is required for the SSL tests. > > Due to the need for 1.4 compatibility, we're using the 1.0.x code > branch of MINA, the latest being 1.0.7. > > It's currently not possible to switch to the 1.1.x branch of MINA > without making some code changes, to make use of the > java.util.concurrent classes, rather than the ones provided in the > backport-util-concurrent JAR. > > Certainly for me this has now become a problem where I've needed to > change the FTP Server code to move forwards and make use of MINA > 1.1.4. Obviously this isn't a patch I can submit, as it will break > our Java 1.4 compatibility. > > We have 3 options:- > > 1) Keep the code as it is, and remain compatible with both Java 1.4 > and Java 1.5. > > 2) Drop Java 1.4, change the code to use MINA 1.1.x and remove the > dependency on backport-util-concurrent. > > 3) Create a 1.4 branch in Subversion. Keep the 1.4 branch as a > maintenance release where only bugs are fixed, and the TRUNK version > will move to Java 1.5, MINA 1.1.x and have all the new development. > > > >
We currently have the situation where the project builds and works with either JVM, although 1.5 is required for the SSL tests. Due to the need for 1.4 compatibility, we're using the 1.0.x code branch of MINA, the latest being 1.0.7. It's currently not possible to switch to the 1.1.x branch of MINA without making some code changes, to make use of the java.util.concurrent classes, rather than the ones provided in the backport-util-concurrent JAR. Certainly for me this has now become a problem where I've needed to change the FTP Server code to move forwards and make use of MINA 1.1.4. Obviously this isn't a patch I can submit, as it will break our Java 1.4 compatibility. We have 3 options:- 1) Keep the code as it is, and remain compatible with both Java 1.4 and Java 1.5. 2) Drop Java 1.4, change the code to use MINA 1.1.x and remove the dependency on backport-util-concurrent. 3) Create a 1.4 branch in Subversion. Keep the 1.4 branch as a maintenance release where only bugs are fixed, and the TRUNK version will move to Java 1.5, MINA 1.1.x and have all the new development.
[ https://issues.apache.org/jira/browse/FTPSERVER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544191
]
Magnus Lind commented on FTPSERVER-116:
---------------------------------------
The default ftpd.properties file is used so it should be the MINA-listener.
> OutOfMemoryError when clients disconnect without issuing a QUIT command.
> ------------------------------------------------------------------------
>
> Key: FTPSERVER-116
> URL: https://issues.apache.org/jira/browse/FTPSERVER-116
> Project: FtpServer
> Issue Type: Bug
> Components: Core
> Reporter: Magnus Lind
>
> I have done some memory profiling regarding this problem:
> The class org.apache.ftpserver.listener.ConnectionManagerImpl stores all connections
it ceates in its conList member variable.
> Normally the connection is removed from conList when it is closed. However, this is only
the case if the client issues a QUIT command before closing the connection.
> Connections for clients that don't issue a QUIT command before disconnecting are left
in the conList variable and never removed.
> As far as I understand, It should be ok to disconnect without issuing a QUIT command.
> When enough connections are left in the conList variable the jvm runs out of memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/FTPSERVER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544060
]
Niklas Gustavsson commented on FTPSERVER-116:
---------------------------------------------
Is this using the MINA or IO listener?
> OutOfMemoryError when clients disconnect without issuing a QUIT command.
> ------------------------------------------------------------------------
>
> Key: FTPSERVER-116
> URL: https://issues.apache.org/jira/browse/FTPSERVER-116
> Project: FtpServer
> Issue Type: Bug
> Components: Core
> Reporter: Magnus Lind
>
> I have done some memory profiling regarding this problem:
> The class org.apache.ftpserver.listener.ConnectionManagerImpl stores all connections
it ceates in its conList member variable.
> Normally the connection is removed from conList when it is closed. However, this is only
the case if the client issues a QUIT command before closing the connection.
> Connections for clients that don't issue a QUIT command before disconnecting are left
in the conList variable and never removed.
> As far as I understand, It should be ok to disconnect without issuing a QUIT command.
> When enough connections are left in the conList variable the jvm runs out of memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
OutOfMemoryError when clients disconnect without issuing a QUIT command.
------------------------------------------------------------------------
Key: FTPSERVER-116
URL: https://issues.apache.org/jira/browse/FTPSERVER-116
Project: FtpServer
Issue Type: Bug
Components: Core
Reporter: Magnus Lind
I have done some memory profiling regarding this problem:
The class org.apache.ftpserver.listener.ConnectionManagerImpl stores all connections it ceates
in its conList member variable.
Normally the connection is removed from conList when it is closed. However, this is only the
case if the client issues a QUIT command before closing the connection.
Connections for clients that don't issue a QUIT command before disconnecting are left in the
conList variable and never removed.
As far as I understand, It should be ok to disconnect without issuing a QUIT command.
When enough connections are left in the conList variable the jvm runs out of memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/FTPSERVER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson closed FTPSERVER-115.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.0-M2
Assignee: Niklas Gustavsson
Thanks! Patch applied.
commit -m "Fixed potential NPE in PASS. Thanks to Dave Roberts for the report and patch (FTPSERVER-115)"
/home/niklas/workspaces/apache/ftpserver/core/src/java/org/apache/ftpserver/command/PASS.java
/home/niklas/workspaces/apache/ftpserver/core/src/java/org/apache/ftpserver/DefaultFtpServerContext.java
Sending /home/niklas/workspaces/apache/ftpserver/core/src/java/org/apache/ftpserver/command/PASS.java
Sending /home/niklas/workspaces/apache/ftpserver/core/src/java/org/apache/ftpserver/DefaultFtpServerContext.java
Transmitting file data ...
Committed revision 596658.
> Potential NPE during processing of PASS command
> -----------------------------------------------
>
> Key: FTPSERVER-115
> URL: https://issues.apache.org/jira/browse/FTPSERVER-115
> Project: FtpServer
> Issue Type: Bug
> Components: Core
> Environment: Latest source from SVN.
> Reporter: Dave Roberts
> Assignee: Niklas Gustavsson
> Priority: Trivial
> Fix For: 1.0-M2
>
> Attachments: ApacheFTPServer_core_20071120.patch
>
>
> Processing of the PASS command could result in an NPE, if the User Manager authentication
scheme passed back a null user.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/FTPSERVER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Roberts updated FTPSERVER-115:
-----------------------------------
Attachment: ApacheFTPServer_core_20071120.patch
This patch avoids the potential NPE.
> Potential NPE during processing of PASS command
> -----------------------------------------------
>
> Key: FTPSERVER-115
> URL: https://issues.apache.org/jira/browse/FTPSERVER-115
> Project: FtpServer
> Issue Type: Bug
> Components: Core
> Environment: Latest source from SVN.
> Reporter: Dave Roberts
> Priority: Trivial
> Attachments: ApacheFTPServer_core_20071120.patch
>
>
> Processing of the PASS command could result in an NPE, if the User Manager authentication
scheme passed back a null user.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Potential NPE during processing of PASS command
-----------------------------------------------
Key: FTPSERVER-115
URL: https://issues.apache.org/jira/browse/FTPSERVER-115
Project: FtpServer
Issue Type: Bug
Components: Core
Environment: Latest source from SVN.
Reporter: Dave Roberts
Priority: Trivial
Processing of the PASS command could result in an NPE, if the User Manager authentication
scheme passed back a null user.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.