I too agree that setIoProcessor isn't all that nice - and what I was trying to think about last night was ways to get away from it. Im not so tired this morning (although 4 hours sleep didn't help much...) but I'll try to explain my approach a bit more clearly. It kind of boils down to a few points:
1) We want to chain "sequences" of filters (a filter chain) together 2) Soon we want to be able to let users build their own filters 3) We want to preserve OOP To me, the current filter chain / filter implementation looks quite complicated. I haven't got familiar enough with the code yet to know whether ths complexity is an unfortunate necessity. Just so we know what my proposed approach is, I'll try and describe the basics here: 1) I don't see how refactoring the chains affects Jose's approach. If we have individual chains, we can still pass them to a builder to be populated 2) Why not make IoFilterChain move towards the composite pattern? A filter chain is just a special type of filter which filters in a sequence. No special head, no special tail. Just a sequence 0..n. So given some "BasicFilterChain" impl, we can add both individual filters and filter chains to the chain. NextFilters can ** still ** be cached by individual filters - no change there. 3) I think filters can still be used ** without ** cloning and without special "setIoProcessor" methods. Asume that we have (2). When a new connection is established, all we have to do is "hook up" our sub chains: BasicFilterChain connectionChain = new BasicFilterChain(); connectionChain.addLast(sessionManagerChain); connectionChain.addLast(portChain); BasicFilterChain sessionChain = new BasicFilterChain(); someChainBuilder.buildChain(sessionChain); // Jose's approach connectionChain.addLast(sessionChain); connectionChain.add(endOfTheLineFilter); And that's it - connectionChain becomes the uniqueue chain for a connection. The last addition, the "endOfTheLineFilter" - is just a filter that does the "real" work (like Niklas' IoProcessor approach - but now encapsulated in a filter). Because this is per-connection, the "endOfTheLine" filter can be provided with the collaborators it needs to do its job without affecting any other filter. This doesn't require any "cloning" of chains, or creation of NextFilters per traversal either. This to me seems like a much cleaner approach - but I must be missing something? 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.
