> 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? Jose Alberto
