Hi Niklas,

2005/11/14, Niklas Therning <[EMAIL PROTECTED]>:
void sessionOpened( IoSession session, IoHandler h ) throws Exception;
void sessionClosed( IoSession session, IoHandler h ) throws Exception;
void messageReceived( IoSession session, Object message, IoHandler h )
throws Exception;
... (I think you get the point)
These are exactly the same as the methods in IoHandler except that the extra
IoHandler argument has been added. The idea is that this should be
propagated through the chain (embedded in the NextFilter class). The tail
filter in a chain will always get the IoHandler from the NextFilter and call
it. When combining IoFilterChains A and B, B is the IoHandler of A while the
real IoHandler is the IoHandler of B.

The nice thing about this is that you can combine an arbitrary number of
IoFilterChains.

This is really interesting.  But wouldn't there be any confusion with IoSession.getHandler() method? 

It also makes it possible to have a setFilterChain() method
on SocketAcceptor and other SessionManagers which make these more
DI-friendly. When using setFilterChain() on an IoAcceptor the acceptor will
call setIoProcessor() on the filter chain.

When you call bind(address, chain, handler) the setIoProcessor() method of
the chain will be called to wire it up with the root filter chain owned by
the IoAcceptor/IoConnector.

I'd rather wrap the IoFilterChain user provided and provide getIoProcessor in the wrapper to make it look more like OOP.  I'm good with setFilterChain() BTW.

Let me know what you think.

The question is how many filter chains we need per session.  Do we need three (IoSessionManager, port, and IoSession) now?  Wouldn't it be too complex?  Actually I was thinking only 2 (port and IoSession).  What is the advantage of IoSessionManager-level filters? 

Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Reply via email to