RE: [mina] Filter management (was Spring Integration)

[Jose Alberto Fernandez]

From: Trustin Lee [mailto:[EMAIL PROTECTED] 2005/11/11, Jose Alberto Fernandez <[EMAIL PROTECTED]>: 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