01-28-06 01:47 AM
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
[ Post a follow-up to this message ]
| 
One issue, why do you need to wrap exceptions in SocketSessionImpl in
> the RuntimeIOException.. why not just have the SocketSessionConfig
> interface declare to throw the exception when necessary? Seems like
> unnecessary wrapping to me.
It's because IoSessionConfigs are shared by both IoSession implementations
and IoServiceConfig implementations. For example,
SocketAcceptorConfig.getSessionConfig() and SocketSessionImpl.getConfig()
will return SocketSessionConfig. The former won't throw any exception until
a new session is created because it just contains the default values of the
new sessions. The latter will throw SocketException because it *really*
modifies socket parameters. I just wrapped SocketException with
RuntimeIOException because the SocketException is rarely thrown for
convenience. Does this make sense?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
