Irving, Dave wrote: >Niklas Therning wrote: > > > >>Yes that's the reason. But I'm not sure exactly what happens when >>the last filter of a filter chain has been executed and control should >> >> > > > >>be transferred to a new chain. The thing is that the code starting the >> >> > > > >>filtering through a chain also has to know what should happen after >> >> >the > > >>chain has completed and create/use the appropriate handler. >> >> > > > >>One possiblity would be to create chains of chains by wrapping them >> >> >two by two. > > >>Let's pretend we have this special IoFilterChain implementation which >> >> >takes > > >>two IoFilterChains (X, Y) and filters through them in order. >>We can use this implementation to combine an arbitrary number of >>chains, (((A, B), C), D). Oh, how I love recursion! :) >> >> > >This is what I was getting at in the last bit of my post (sorry - I read >it back and it didn't make much sense to me either - really shouldn't do >these 14 hour days :o) > >I was thinking that chaining chains directly (as you describe above) >might be cleaner than having a chain masquerade as a handler. > >So Im thinking that maybe the "ChainedFilterChain" or what-ever might be >a good way. > > > > >>The head and tail should not be needed anymore. >>The Upstream/DownstreamNextFilters will know what to do when there are >> >> >no more filters. > >As I understand it though, they will currently either delegate to the >IoHandler or to the IoProcessor. >And I think that's why you passed the handler through (so the next chain >can masquerade as a handler). >But I think we're maybe agreeing that a "ChainedFilterChain" is maybe a >cleaner approach (presumably to chain the per acceptor / connector chain >with the per session chain?). >So, given that: > > > >>>That way, you'd just have something like >>>IoFilterChain#chain(IoFilterChain next). Any special meaning to the >>>tail operations would be at a higher level. >>>(Again, clear in my head - but that doesn't mean anything :o) >>> >>> >>> > > > >>That doesn't make sense in my head! :) Though I am a bit sleepy at the >> >> >moment. Please elaborate. > >That's my dumb way of saying that Im wondering whether the chain >implementation ** itself ** should even know or care about the "final >tasks" (i.e: Performing operations on the IoHandler or the IoProcessor). >If the chain just invokes filters until there are no more filters, then >the chain interface (and implementation) is pretty simple - and it >becomes very easy to "chain chains" using the "ChainedFilterChain" I >alluded to and you described. > >Then there are endless possibilities to how filters and chains could be >attached together. >For example, you could even have IoFilterChain implement (directly, or >via adaptor) IoFilter. >Then you might have something real simple like this: > >-------------------------------------------------- >BasicFilterChain chain = ... // some basic impl - like >AbstractFilterChain is now >IoFilter sessionManagerFilter = ... // really a filter chain! >IoFilter sessionFilter = .... // really a filter chain! >chain.addLast(sessionManagerFilter); >chain.addLast(sessionFilter); > >// Dummy name: This is the filter that delegates to IoHandler, >IoProcessor >EndOfTheLineFilter endOfTheLineFilter = ... > >chain.addLast(endOfTheLineFilter); >-------------------------------------------------- > >This should also fit in with the DI stuff too. >I hope this makes a little more sense. But if it doesn't - I can >certainly discuss further when Im more awake :o) >(Been working since 7am, and its 10pm now - so Im more than a little >drained :o) > >Any comments would be greatly appreciated.... > > > I really like your way of thinking! I will have to get back to you on this tomorrow when my brain is functioning properly again. At the moment, all I can say is that all this looks very nice to me.
/Niklas
