Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of bengt.rodehav@gmail.com
 designates 72.14.220.154 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:date:x-google-sender-auth:message-id:subject
         :from:to:content-type;
        b=aFod3iBIjR1z2cNdfn3rjC7I6X1lPpUKrTw39ms/e2qcB//rmn/N5VoR11uQBo+HzV
         n4362X7btdeGwqvO46mhMoiulVcZBQx+bJGCxKUX7ed8FlXXVyU4iFaaNzZ/3qc1IMkT
         c7ZB1ldW8jwNZKarkPjyVxj7+MhoZKaqzp5nE=
MIME-Version: 1.0
Sender: bengt.rodehav@gmail.com
Date: Thu, 17 Jun 2010 17:13:30 +0200
Message-ID: <AANLkTilzf8HJzOkArarrikaV3RcpcQKQ01OlHeLGH2U_@mail.gmail.com>
Subject: "Unconnected sockets not implemented" using Commons Net ftps support
From: Bengt Rodehav <bengt@rodehav.com>
To: user@commons.apache.org
Content-Type: multipart/alternative; boundary=00151747363ef69a7404893b47b9

--00151747363ef69a7404893b47b9
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I'm using Apache Camel as an integration platform. Specifically, at the
moment, I depend on the ftp/ftps/sftp support in the camel-ftp component.
Under the hood Camel uses Commons Net for ftp and ftps support.

Recently, the camel-ftp component was enhanced (on my request) with the
possibility to use a secure data channel. This is accomplished by using the
execProt() (and execPsbz()) method in class FTPSClient. Unfortunately the
execProt() method also sets the FTPSClient's socket factory to a new
instance of FTPSSocketFactory. I'm sure there is a good reason for this that
I'm not aware of.

However, later on (in case Camel needs to reconnect), one of the connect()
methods in SocketClient (the ultimate base class of FTPSClient) is called.
Unfortunately all the connect methods first create an unconnected socket and
then tries to connect it. The connection factory now associated with the
FTPSClient the throws an exception stating that "Unconnected sockets not
implemented".

I've looked at the source code in commons-net trying to find out what's
happening. These are my findings:

The FTPSSocketFactory class override the createSocket() methods in
SocketFactory and delegates them to its SSLContext's socket factory. Thus
it's the SSLContext's connection factory that is being used.

Since we are able to initially connect (the problems are related to
reconnecting using the same FTPSClient instance) we need to investigate
exactly what execProt() does that makes further connection attempts to fail.

Lets have a look at the FTPSClient class. When the initial connection is up,
the _connectAction() method is called. It in turn calls sslNegotiation()
which in turn sets up the secure socket. In the sslNegotiation() method, an
SSLSocketFactory is not instantiated directly. It is given by the
SSLContext's getSocketFactory() method. This connection factory obviously
works otherwise the secure connection wouldn't work even initially.

Compare this with what's being done in the execProt() method. Here the
FTPSSocketFactory is instantiated directly with the SSLContext passed as a
constructor argument. Obviously this factory does NOT work...

A question that comes to mind is why the socket factory created in the
sslNegotiation() method is NOT set as the SocketClient's socket factory but
the one created in the execProt() method is? It turns out that execProt()
calls a generic sendCommand() method that sends the command and if the reply
is OK, then sets the socket factory to null! One wonders why (and there is
also a comment in the code: "Check this - is this necessary at all?")?
Anyway, this is probably the reason why execProt() needs to "reset" the
connection factory.

Can anyone help me out with this? I need to get ftps (with a secure data
channel) working in Camel.

Is it a bug in the FTPSClient class or are we using it the wrong way? Should
it be possible to reuse an instance of FTPSClient or must a new FTPSClient
instance be created on every reconnect?

/Bengt

--00151747363ef69a7404893b47b9--