directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [mina] Filter management (was Spring Integration)
Date Thu, 10 Nov 2005 19:26:53 GMT
 

 

________________________________

From: Trustin Lee [mailto:trustin@gmail.com] 



2005/11/11, Jose Alberto Fernandez <jalberto@cellectivity.com>:

public void sessionCreated( IoSession session ) throws Exception {
    session.getFilterChain().addFirst( "codec", new ProtocolCodecFilter(
YOUR_CODEC_FACTORY ) );
}

This is one place, where the approach I mentioned would make a lot of
sense. You are running several protocols using several different
handlers. You really do not want to specify on every session the adding
of new CodecFilters, for example. You know all sessions will use the
same filters and if your filters are stateless, they should be using the
same one. It would make a lot of sense to be able to set this things
once during bind() and not need to do it on every session creation.

For now, you can add ProtocolCodecFilter to IoFilterChain of
IoSessionManager to apply it to all connections managed by an acceptor
or a connector.  This is not per-port way, but I suggested an API change
in this thread. 

 

This assumes you use only one Protocol on your server. 

I think we all agree the correct strategy is to provide a way to define
different IoFilterChains per port. The stick point here is how should we
define the different chains. On the table are three different approaches
(they apply to bind and connect):

 

1) Niklas: acceptor.bind(address, chain, handler).
    Where chain will be plugged at the end of the acceptor chain.
(Problem: you can only add filters no way to do anything else).

 

2) Trustin: acceptor.bind(address, handler);
acceptor.getFilterChain(address.name).add...
You can access the per port chain after the binding and modified as you
please. (Problem: what happen if clients arrive before you modify the
chain).

 

3) Jose: acceptor.bind(address, handler implements FilterManager).

During bind, is handler implements FilterManager, it is called to set-up
the chain for the port appropriately. (Problem: cannot use same handler
for similar protocols)

 

I also proposed, having an additional bind with three arguments for this
scenario:

 

4) acceptor.bind(address, manager, handler).

In escence, a simple implementation can make the following to be true:

 

Public Session bind(SocketAddress address, IoHandler handler) {

          return  bind(address, (handler instanceof FilterManager?
handler : null), handler);

}

 

This I think would address Niklas issues, as he can express what he
wants. There are other issues here, but would address this separately.

 

Please note that our versioning strategy is that of Linux.  0.9 (odd) is
unstable release. 0.8 (even) is stable. The API and feature set of 0.9
and 0.9.1 can be different dramatically.

 

What I meant was 1.0 which would be the next stable release.

 

Jose Alberto

 


Mime
View raw message