Some commonly encountered problems and their resolution are described below.
Before you contact EDT Support, check this list and also go through the How to diagnose problems topic.
Unusual ClassCastExceptions. When edtFTPj/PRO is used in application servers such as Tomcat or Weblogic, you may get unusual ClassCastExceptions. This is generally due to multiple classloaders.
The edtFTPj/PRO jar file should only be located in one place on the application server. If it is located in a common library directory as well as an application context, this error is possible.
ParseException using dirDetails(). edtFTPj/PRO supports as many server directory listing formats as possible, however occasionally unknown formats arise. However this problem can also occur if the client is in
a different locale to the server. edtFTPj/PRO cannot easily work out the locale of the server, and thus FTPClient.setParserLocale() can be used to force the client to use a particular server's locale.
Signer information does not match. edtFTPj/PRO's jar file is digitally signed. An error such as "class com.enterprisedt.net.ftp.FTPClient's signer information does not match signer information of other
classes in the same package" generally indicates that an unsigned jar containing the same class has been loaded from the CLASSPATH. This is usually because edtFTPj's jar file is also in the CLASSPATH.
Ensure that edtftpj.jar and edtftpj-pro.jar are not both in the CLASSPATH, i.e. remove edtftpj.jar from the CLASSPATH.
Failing to create sockets (IOException). Generally, applications have a limit to the number of sockets they can have open simultaneously (in Unix this is controlled via ulimit).
This wouldn't be a problem if sockets disappeared as soon as they were closed. In TCP/IP, however, when sockets are closed they enter the TIME_WAIT state. The socket stays in this state long enough to
let stray TCP packets for this connection expire - usually up to 2 minutes. Since every data transfer and directory listing uses a new socket, if a large number of transfers are performed quickly,
the number of sockets in TIME_WAIT can build up rapidly and the application run out of sockets. There are various solutions. The length of time a socket is in TIME_WAIT can be decreased (not a good idea
generally). The number of sockets available to an application can be increased via ulimit (Unix) or via the MaxUserPort registry parameter (Windows). Preferably, it is best to space out transfers a little
so sockets have a chance to expire from TIME_WAIT, or catch the exception, sleep and retry repeatedly.
How to contact support
See here for details on contacting support. Please ensure all the requested items are included.