Niklas Therning wrote: >I really like your approach, Dave. Some question though: > What would session.getFilterChain() return? It will be sessionChain, right?
Yes. This allows IoHandlers or who-ever to contribute to the session chain. They ** never ** get access to the "connection chain" (which is a private implementation detail of SocketAcceptorDelegate etc). > Will IoFilterChain extend IoFilter and be just another IoFilter? Depends. I think at the moment there's not all that much need for true composite - as Trustin says. However, I don't think its any more or less work either way - and I think its cleaner to have a chain as a special type of filter. However, this ** could ** be blown away by the NextFilter problem. > This is basically the same as nesting filter chains as I proposed yesterday (remember the (((A, B), C), D) thingy?) > but it's a flat list of chains instead, right? Yeah - I think we were both talking about the same thing all along but didn't realise it in our respective tiredness :o) > You still have the NextFilter problem. > As I understand it these have to be static since IoFilter.init() is called when the filter is added to a chain. > A NextFilter is passed to this method and the filter could remember this for future use. Yes - I certainly do have a NextFilter problem. This is quite similar to the "this problem" often found when employing the decorator pattern. Im going to spend some time this morning thinking about how we can get round it cleanly and transparently: But I understand that support for NextFilter caching is required, important, and must not be lost. > I can't see how the last filter in a wrapped chain will know where to go next if the NextFilter given > to it can't be created dynamically. > Remember, sessionManagerChain and portChain will be shared by many connectionChains. Yep - Im going to have to think about that this morning / this afternoon. However, I believe that finding a solution is worth it - as Im sure we're on to a clean solution :o) > /Niklas Dave 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.
