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.
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?
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
