2005/11/15, Niklas Therning <[EMAIL PROTECTED]>:
If we're going to use setfilterChain only for the initial configuration, then we can copy. Otherwise we cannot. The problem here is that we cannot easily reuse IoFilterChain because it contains too much information.
Trustin
-- Trustin Lee wrote:
> 2005/11/15, Niklas Therning <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>:
>
> I just realized that when calling IoSession.write() the concrete
> IoSession implementation will always know the final destination of the
> write event. For SocketSessionImpl the final destination is always
> SocketIoProcessor.
>
> So the IoFilterChain methods for downstream events look like this:
>
> void write( IoSession session, WriteRequest writeRequest,
> IoProcessor p
> ) throws Exception;
>
> SocketSessionImpl's write() method looks like this:
>
> public WriteFuture write( Object message ) {
> this.filterChain.write(this, new WriteRequest(),
> SocketIoProcesso.getInstance ());
> }
>
>
> What is the difference from overriding the head filter of
> sessionmanager-level chain to call SocketIoProcessor.flush()
> explicitly? We can still get rid of SocketSessionManagerFilterChain
> without introducing a new parameter.
>
If the user can change the filter chain of an IoAcceptor by calling
setFilterChain() you won't be able to override any method to inject this
behaviour. Likewise if there is a bind(address, chain, handler) method.
Unless you copy the user supplied chain into some IoFilterChain
implementation which we have control over. And from what I understand
copying is out of the question. Or am I missing something?
If we're going to use setfilterChain only for the initial configuration, then we can copy. Otherwise we cannot. The problem here is that we cannot easily reuse IoFilterChain because it contains too much information.
Trustin
what we call human nature is actually human habit
--
http://gleamynode.net/
