directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [mina] Filter management (was Spring Integration)
Date Sat, 12 Nov 2005 17:18:57 GMT


At the end you will have the last word, but I really do not see how
Niklas approach can be of any help when you do not know the
implementation of a protocol in some other package. Lets assume Niklas
preferred example which is SSL/no SSL enabled protocols.


Now, I have a protocol implementation provided by an IoHadler that as
part of setting the protocol up, on every sessionCreated() will put the
following filters:

1)       A multi-thread filter.

2)       A codec filter

3)       Some authentication filter


Now Niklas wants to run this using SSL. He creates a filter chain
containing the SSL filter and passes it as the initial chain.

The result is that SSL will be executed not in a multi-threaded fashion,
because it will be before the multi-threading filter.


Alternatively, he may pass a chain with both multi-thread and SSL, but
then you finish with two multi-thread filters which seems kind of
wasteful. What you really want is to set up SSL after the multi-thread
filter, but that you cannot do by specifying an initial filter chain.


So how are people to use this facility in the generic case, if you do
not know what the protocol component is actually doing?


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) {


                        s.getFilterChain().addAfter("threadFilter", new




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.


Jose Alberto



From: Trustin Lee [] 
Sent: 12 November 2005 06:08
To: Apache Directory Developers List
Subject: Re: [mina] Filter management (was Spring Integration)


Hi Jose,

2005/11/11, Jose Alberto Fernandez <>:

Niklas provided a preconstructed IoFilterChain, I am passing the code to
construct the IoFilterChain. That is the only difference. Should the
person doing the binding know which filters are needed for a protocol
provided in some other package? Or should that be expressed as part of
the code in the package providing the protocol implementation?


Now I see the main difference between the two approaches.  Let's
reanalyze the two:

* Jose's approach

The problem here is that IoFilterChain contains some
transport-type-specific code so we cannot simply create and construct
it.  So a new interface 'IoFilterChainBuilder' (I think 'builder' is
better than manager here) is introduced. 

* Niklas's approach

His approach has advantage over Jose's one because it doesn't introduce
any new interface that a user has to learn.  But IoFilterChain contains
some transport-type-specific code as I mentioned above.  We'll have to
create an implementation of IoFilterChain which is independent from any
transport-type.  It should be easy and will be reusable because this
chain will be copied into the internal filter chain implementation. 

I think Niklas's approach is better because it doesn't introduce a new
interface and Jose's approach can be implemented as a simple factory.


what we call human nature is actually human habit 

View raw message