Hi! Besides the points you mentioned, there are some other flaws: 1) How do you handle post-message-forwarding logic? 2) How do you handle filters that transparently push messages to the underlying filters (e.g. keep alive)?
So the filters should decide about what to do, the chain about the where. regards Steve There could be specific (empty, single-result, multi-result) implementations that can be extended as needed. > Julien Vermillard [mailto:[email protected]] wrote: > > Hi, > I implemented some really simple chain for MINA 3 based on a list of > chain processed by a filter chain. > > The implementation is very simple, sounded like a good idea : > http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/or > g/apache/mina/filterchain/DefaultIoFilterChain.java > > But when i started implementing an HTTP codec I started to see the > real design issues. > The problem is when you need to produce more than one object during a > filter processing, like when you find more than one PDU in a > ByteBuffer. > > We could change IoFilter method : > Object messageReceived(IoSession session, Object message); > To : > List<Object> messageReceived(IoSession session, Object message); > > But starting to use collection here sound like an overkill and not > really a nice idea if we want to keep the memory usage low enough. > > So I'm scraping the current implementation, I'm going to try something > else suggested by Emmanuel : > When a filter want to call the next filter, he ask it to the filter > controller (aka the FilterChain). Let's see if it's going somewhere > this time ;) > > Julien >
