directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <>
Subject RE: [mina] IoFilters: DIRMINA-121 / 122
Date Mon, 14 Nov 2005 19:07:16 GMT

Im just starting to have a look at this now - and I have a couple of
If you could help me in clearing them up that would be greatly

> Today we have SocketSessionManagerFilterChain,
DatagramSessionManagerFilterChain, and so on. 
> This makes it hard to combine arbitrary IoFilterChains into longer
chains which is 
> required for DIRMINA-121.


> Add a new interface which is the counter part of IoHandler. 
> I don't have a good name for it, let's call it IoProcessor for now. 
> IoProcessor looks something like this:

> public interface IoProcessor {
>    void write( IoSession session, WriteRequest writeRequest );
>    void close( IoSession session, CloseFuture closeFuture ); }

The way I understand this is that the concrete "do a write / do a close"
behaviour used to be embedded in the concrete filter chain
implementations. E.g: SocketSessionManagerFilterChain knows how to do a
"real" write / close for a socket session. What we are doing here is
extracting this behaviour in to a sort of "strategy" interface which we
can plug in to any chain. Correct?

> Add some methods to the IoFilterChain interface:

> void setIoProcessor( IoProcessor p );

Makes sense if Im correct above. I.e: plug in the "processor" strategy
for the chain.

> void sessionOpened( IoSession session, IoHandler h ) throws Exception;

> void sessionClosed( IoSession session, IoHandler h ) throws Exception;

> void messageReceived( IoSession session, Object message, IoHandler h )
throws Exception; ... 
> (I think you get the point)

Replacing the sessionOpened(IoSession) / sessionClosed(IoSession) et al
methods in AbstractFilterChain?

> These are exactly the same as the methods in IoHandler except that the
extra IoHandler argument has been added. > > The idea is that this
should be propagated through the chain (embedded in the NextFilter

This is where my real question comes in: You say later that we shouldn't
need to refactor existing filter implementations. 
How are we going to pass the handler through transparently without
changing the IoFilter / NextFilter interface?
I think this is the bit Im missing at the moment :o)

> When you call bind(address, chain, handler) the setIoProcessor()
method of the chain will be 
> called to wire it up with the root filter chain owned by the

Yep - plugging in its own strategy to the chain. Sounds good.

> I don't think it will require any refactoring of existing filters. 

See question above

> It will also eliminate a couple of interface/classes (like the

Cool! I love removing classes :o)

Cheers for your help,


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.

View raw message