|
Home > Archive > Apache Directory Project > January 2006 > [mina] New configuration API
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[mina] New configuration API
|
|
| Trustin Lee 2006-01-27, 8:47 pm |
| 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
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
| |
| Niklas Therning 2006-01-27, 8:47 pm |
| 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
| |
| Trustin Lee 2006-01-27, 8:47 pm |
| Hi Niklas,
2006/1/26, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>:
>
> 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.
Great.
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.
There's no IoService.setDefaultConfig() for now. We can add it if it is
required for spring integration. Please let me know.
Acceptor-wide filter chains were removed for now, but I will revive it.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Trustin Lee 2006-01-27, 8:47 pm |
| 2006/1/26, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> Acceptor-wide filter chains were removed for now, but I will revive it.
>
Done.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| peter royal 2006-01-27, 8:47 pm |
| | |
| Trustin Lee 2006-01-27, 8:47 pm |
| Hi Peter,
2006/1/26, peter royal <peter.royal-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>:
>
> I like this change! Very nice!
Thanks! 
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
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| peter royal 2006-01-27, 8:47 pm |
| |
|
|
|
|