directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <>
Subject RE: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)
Date Tue, 15 Nov 2005 08:59:24 GMT
I too agree that setIoProcessor isn't all that nice - and what I was
trying to think about last night was ways to get away from it.
Im not so tired this morning (although 4 hours sleep didn't help
much...) but I'll try to explain my approach a bit more clearly.
It kind of boils down to a few points:

1) We want to chain "sequences" of filters (a filter chain) together
2) Soon we want to be able to let users build their own filters 
3) We want to preserve OOP

To me, the current filter chain / filter implementation looks quite
complicated. I haven't got familiar enough with the code yet to know
whether ths complexity is an unfortunate necessity.
Just so we know what my proposed approach is, I'll try and describe the
basics here:

1) I don't see how refactoring the chains affects Jose's approach. If we
have individual chains, we can still pass them to a builder to be
2) Why not make IoFilterChain move towards the composite pattern? A
filter chain is just a special type of filter which filters in a
sequence. No special head, no special tail. Just a sequence 0..n. So
given some "BasicFilterChain" impl, we can add both individual filters
and filter chains to the chain. NextFilters can ** still ** be cached by
individual filters - no change there.
3) I think filters can still be used ** without ** cloning and without
special "setIoProcessor" methods. Asume that we have (2). When a new
connection is established, all we have to do is "hook up" our sub

BasicFilterChain connectionChain = new BasicFilterChain();
BasicFilterChain sessionChain = new BasicFilterChain();
someChainBuilder.buildChain(sessionChain); // Jose's approach


And that's it - connectionChain becomes the uniqueue chain for a
connection. The last addition, the "endOfTheLineFilter" - is just a
filter that does the "real" work (like Niklas' IoProcessor approach -
but now encapsulated in a filter). Because this is per-connection, the
"endOfTheLine" filter can be provided with the collaborators it needs to
do its job without affecting any other filter.
This doesn't require any "cloning" of chains, or creation of NextFilters
per traversal either.

This to me seems like a much cleaner approach - but I must be missing


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