directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)
Date Tue, 15 Nov 2005 13:50:25 GMT
> From: Irving, Dave [mailto:dave.irving@logicacmg.com]
> 
> 
> >> It kind of boils down to a few points:
> >>
> >> 1) We want to chain "sequences" of filters (a filter chain)
together
> 
> > Ok, why is it that we want to do this? What is it that we are trying
> to solve?
> 
> One motivation is that concrete chain implementations currently
specify
> "end of chain" behaviour (e.g: SocketSessionManagerFilterChain,
> DatagramSessionManagerFilterChain etc).
> When we were originally looking at implementing 121 / 122, Niklas
> suggested that it would be nice to refactor this - and I agree - as it
> makes it more difficult to chain arbitrary filter chains in to longer
> chains.

Why is it that we want to chain arbitrary filter chains into longer
chains?
It seems that the reason for the requirement is the requirement itself.
But what is the reason for it?

I may be mistaken, but it seems to me the whole reason for this is to be
able, eventually, to specify a chain in a spring based model and set it
up during configuration. Am I off the mark here?

Wouldn't it be simpler (or less disruptive) to simply configure some
other object (lets say a ChainBuilder) with all the filters one
requires, and during execution (the call to build) it will just add all
the filters to the chain programmatically. No need to re-engineer
everything just one smart spring aware builder.

Would this solve any of the user patterns we are trying to deal with in
here?

Jose Alberto


Mime
View raw message