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

[Jose Alberto Fernandez]

From: Trustin Lee [mailto:[EMAIL PROTECTED] Sent: 13 November 2005 01:58 To: Apache Directory Developers List Subject: Re: [mina] Filter management (was Spring Integration)   Jose, 2005/11/13, Jose Alberto Fernandez <[EMAIL PROTECTED]>: This is just a simple example, for many protocols one could come up with several scenarios where you can have similar issues. For example is I want to setup a different authentication filter and so on. This is why I think you need to provide a way to manipulate the filter chain. Now, Niklas could achieve what he wants by just extending the IoHandler: Handler =  New XYZIoHandler() {             public void sessionCreated(Session s) {                         super(s);                         s.getFilterChain().addAfter("threadFilter", new SSLFilter(…));             }   } What's wrong with all this? It does not look too efficient that you need to set up the same filters on every session creation. It seems to me much more efficient to configure them once when binding to the port and reuse it for every session. Now to do that you need some event call that allows for this global configuration to be set up at binding time. Your IoFilterChainManager doesn't accept IoSession as a parameter, so it cannot configure IoSession-level filters, either.  Am I missing something here? The example above was using the current mina 0.9 API as is. Without neither mine nor Niklas changes. Sorry, if I confused you. Now, if we were to use my proposed approach, then I would assume that most filters for a protocol will be setup on the FilterManager and not on each session. So the approach is quite similar. Now let's compare the two by example again: 1) Jose's approach public class MyFilterChainBuilder implements IoFilterChainBuilder {     private final IoFilter TPF = new ThreadPoolFilter();     private final IoFilter SSLF = new SSLFilter();     public void buildFilterChain(IoFilterChain chain) { // this is a SessionManager-level chain         chain.addLast( "threadPool", TPF );         chain.addLast( "SSL", SSLF );      } } acceptor.bind( addr, myFilterChainBuilder, myHandler); 2) Niklas's approach public class MyFilterChainFactory {     private static final IoFilterChain COMMON_CHAIN;     static {         COMMON_CHAIN = new SimpleIoFilterChain();         COMMON_CHAIN.addLast( "threadPool", new ThreadPoolFilter() );         COMMON_CHAIN.addLast( "SSL", new SSLFilter() );     }     public static IoFilterChain getInstance() {         return (IoFilterChain) COMMON_CHAIN.clone();     } } acceptor.bind (add, MyFilterChainFactory.getInstance(), myHandler); I thought these are identical?   Well, they are very similar however, in (2) you need to call “new SimpleIoFilterChain()” which means MINA is not in control of what filter-chain implementation to use, you are exposing this to the users. Now if you let MINA pass the empty MINA filter chain object to this implementation, your code can refer just to interfaces as it should. That is really the only difference.   Jose Alberto