Hi
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;
__commandBuffer.setLength(0);
__commandBuffer.append(command);
if (args != null)
{
__commandBuffer.append(' ');
__commandBuffer.append(args);
}
__commandBuffer.append(SocketClient.NETASCII_EOL);
try{
_controlOutput.write(message = __commandBuffer.toString());
_controlOutput.flush();
}
catch (SocketException e)
{
if (!isConnected() || !socketIsConnected(_socket_)) <<<<<<<<<<
{
throw new FTPConnectionClosedException("Connection
unexpectedly closed.");
}
else
{
throw e;
}
}
if (_commandSupport_.getListenerCount() > 0)
_commandSupport_.fireCommandSent(command, message);
__getReply();
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:
Hi
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!
/niklas
Peter Kostouros wrote:
Hi
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
--
Regards
Peter
As always the organisation disavows knowledge of this email
