On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;)
I ran into a different scenario that dictated the same result. For me, often times when a message is sent or received no message is passed on so my protocol had to always return a null. This always seemed awkward to me. Also, then that dictated that I had to check for nulls in the framework, also not so good. Take a look at my class org.apache.mina.link.UpState to see what I mean. Regards, Alan
