Jose Alberto Fernandez wrote:
From: Irving, Dave [mailto:[EMAIL PROTECTED]
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?
I've actually thought of adding such a feature to the
AbstractIoAcceptorFactoryBean. I think it would require a proxy for the
real IoHandler which intercepts sessionCreated() and simply adds the
appropriate port-specific filters to the session's filter chain before
forwarding to the real IoHandler. It's not a bad idea at all and I might
do it that way in the meantime. Thanks for pointing that out! :)
But I also think that the refactoring Dave is working on will make the
code simpler to understand/maintain and give more flexibilty. Let's see
what he comes up with and take it from there.
/Niklas
