Trustin Lee wrote:
On 10/19/06, Niklas Therning <[EMAIL PROTECTED]> wrote:
Trustin Lee wrote:
> On 10/19/06, Niklas Therning <[EMAIL PROTECTED]> wrote:
>>
>> I like this change a lot because (as you've already metioned) it
>> simplifies configuration a lot, especially when using Spring. My only
>> concern is that it won't be as straight forward to setup connectors
>> using Spring. I guess one approach would be to have a factory for
each
>> type of IoConnector. E.g.:
>>
>> public class SocketConnectorFactory implements IoConnectorFactory {
>> SocketConnector createConnector(SocketAddress addr);
>> void setFilters(...);
>> void setConnectTimeout(...);
>> ... other relevant properties
>> }
>
>
> What is the advantage of having a factory for connector? Connector
> implementations already provide all properties you can configure.
Ok, let me explain a little further. Today I configure two
SocketConnectors using Spring, one for plain text connections and one
for SSL connections. The app is a kind of proxy. When my acceptor has
accepted a connection my code will determine which remote host to
connect to and whether the connection should be encrypted or not and use
the appropriate connector configured using Spring.
My concern is that I'd like to be able to keep the configuration of the
outgoing connections (in particular the filter chains) in Spring but I'm
not sure whether that will be as easy with these new connectors? But
maybe I have totally misunderstood the changes?
With the SocketConnectorFactory I would just setup one which has no
SSLFilter in its filter chain and one which has and then configure my
code with these. Then in my code I would do:
IoConnector connector = null;
if (useSSL) {
connector = sslConnectorFactory.create();
} else {
connector = connectorFactory.create();
}
connector.setRemoteAddress(address);
connector.connect();
whenever I need to establish a new outgoing connection.
Now I see your concern. It is because the remote address cannot be
changed
once connect() is invoked, right? Actually I was thinking of taking
advantage of clone() method. You could create a template connector
and call
clone() whenever you want to create a new instance with the same setting.
We you need to do next is to change some properties like remoteAddress
and
call connect(). It feels like a hack, but it might be better than
creating
as many factories as the number of IoService implementations, once we
migrate to Java 5 and utilize covariant return type. WDYT?
Trustin
I think a good compromise would be to keep the connect(address) method
of IoConnector but get rid of the IoServiceConfig. An IoConnector would
simply be configured directly using properties on it. That makes
configuration a lot easier.
IMO, keeping connect(address) would give symmetry between IoAcceptor and
IoConnector. IoAcceptor handles multiple *incoming* connections for a
single IoHandler while IoConnector handles multiple *outgoing*
connections for a single IoHandler.
WDYT?
--
Niklas Therning
www.spamdrain.net
