________________________________

From: Trustin Lee [mailto:trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.or
g] 
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 <jalberto-FQMVDHFwfny6lNtOUNzE6A@public.g
mane.org>:

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

[ Post a follow-up to this message ]