Hi,
From a Spring integration perspective I think this is a nice change. We
won't need different Spring FactoryBeans anymore for every IoAcceptor
and IoConnector implementation like we need today. We'll just need a
single IoAcceptorFactoryBean and IoConnectorFactoryBean. You specify the
actual implementaion as a Class property. And then you configure the
transport specific Config object. Since it will have setters for
everything configurable we won't need FactoryBeans for those.
Maybe there should be a default Config object that you set directly on
the IoAcceptor/IoConnector? I think there should at least still be a
setFilterChainBuilder() method on the IoAcceptor so that we can
configure Acceptor global filter chains.
/Niklas
Trustin Lee wrote:
Hi all,
This time, I refactored configuration API in
'sandbox/trustin/dirmina-158'. Here's the link to the related JIRA issue:
http://issues.apache.org/jira/browse/DIRMINA-158
<http://issues.apache.org/jira/browse/DIRMINA-158>
Here's the summary of what I've done in the branch:
* New interface: IoServiceConfig (includes filter chain builder
configuration)
* New interface: IoAcceptorConfig extends IoServiceConfig (includes
disconnectClientsOnUnbind property)
* New interface: IoConnectorConfig extends IoServiceConfig (includes
connectTimeout property)
* New interface: IoSessionConfig (just an empty tag interface)
* All configuration getters and setters in transport-type specific
acceptors, connectors, and sessions are moved to the implementations of
the above interfaces.
** New method: IoService.getDefaultConfig(); // This is used when user
didn't specify the configuration when you call bind() and connect().
** Changed method signature: IoAcceptor.bind( SocketAddress, IoHandler,
IoServiceConfig ); // Instead of IoFilterChainBuilder
** Changed method signature: IoConnector.connect( SockeetAddress,
IoHandler, IoServiceConfig ); // instead of IoFilterChainBuilder
Before the refactoring:
SocketAcceptor acceptor = new SocketAcceptor();
acceptor.setReuseAddress( true );
acceptor.bind( ... );
...
acceptor.setReuseAddress( false );
acceptor.bind( ... );
After the refactoring:
IoAcceptor acceptor = new SocketAcceptor();
SocketAcceptorConfig config1 = new SocketAcceptorConfig();
config1.setReuseAddress( true );
acceptor.bind( ..., config1 );
SocketAcceptorConfig config2 = new SocketAcceptorConfig();
config2.setReuseAddress( false );
acceptor.bind( ..., config2 );
The length of the code increased after the refactoring, but the former
brings a mispreception that 'reuseAddress' property of all services
bound to the acceptor is 'true'.
Because of all these configuration classes, there's no more session
interface for specific transport type (e.g. SocketSession). Instead,
you have an IoSessionConfig implementation for the specific transport
type. ( e.g. SocketSessionConfig). For example:
IoSession session = ...;
SocketSessionConfig cfg = ( SocketSessionConfig ) session.getConfig();
cfg.setReceiveBufferSize( 2048 );
The downside of this refactoring is that it makes us to downcast
returned values too frequently when we change some settings. I think
this issue can be resolved by Covariant Return Type, which is introduced
with Java 5. We might have to consider to support Java 5 for simplicity.
As always, your feedback is welcome.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
