I had a look at the commons ftp code and the following snippet may help us understand what is going on:

    * Sends an FTP command to the server, waits for a reply and returns the
    * numerical response code.  After invocation, for more detailed
    * information, the actual reply text can be accessed by calling
    * [EMAIL PROTECTED] #getReplyString  getReplyString } or
    * [EMAIL PROTECTED] #getReplyStrings  getReplyStrings }.
    * <p>
    * @param command  The text representation of the  FTP command to send.
    * @param args The arguments to the FTP command.  If this parameter is
    *             set to null, then the command is sent with no argument.
* @return The integer value of the FTP reply code returned by the server
    *         in response to the command.
    * @exception FTPConnectionClosedException
    *      If the FTP server prematurely closes the connection as a result
    *      of the client being idle or some other reason causing the server
    *      to send FTP reply code 421.  This exception may be caught either
    *      as an IOException or independently as itself.
* @exception IOException If an I/O error occurs while either sending the
    *      command or receiving the server reply.
   public int sendCommand(String command, String args) throws IOException
       String message;


       if (args != null)
           __commandBuffer.append(' ');

       _controlOutput.write(message = __commandBuffer.toString());
       catch (SocketException e)
           if (!isConnected() || !socketIsConnected(_socket_))  <<<<<<<<<<
throw new FTPConnectionClosedException("Connection unexpectedly closed.");
               throw e;
       if (_commandSupport_.getListenerCount() > 0)
           _commandSupport_.fireCommandSent(command, message);

       return _replyCode;

Is it worthwhile adding SocketException catch clauses to tests expecting FTPConnectionClosedException exceptions? or is something else going on that should not?

Niklas Gustavsson wrote:

I've commited a change for this. Not really sure what causes the problem but the test now allows for a SocketException as well.

Keep on reporting!


Peter Kostouros wrote:

DefaultMaxLoginTest and CustomMaxLoginTest are failing on a Unix/Linux environment: SocketExceptions are raised whereas FTPConnectionClosedExceptions are expected.

FTPConnectionClosedException documentation mentions that such exceptions are raised when an FTPReply.SERVICE_NOT_AVAILABLE|| <http://commons.apache.org/net/apidocs/org/apache/commons/net/ftp/FTPReply.html#SERVICE_NOT_AVAILABLE>| |response (421) is received to a failed FTP command. I have not noticed this error under a Windows environment.

Here is the surefire report for DefaultMaxLoginTest.

Test set: org.apache.ftpserver.clienttests.DefaultMaxLoginTest
------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.693 sec <<< FAILURE! testLogin(org.apache.ftpserver.clienttests.DefaultMaxLoginTest) Time elapsed: 1.686 sec <<< ERROR!
java.net.SocketException: Connection reset




As always the organisation disavows knowledge of this email

Reply via email to