directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <>
Subject Re: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)
Date Tue, 15 Nov 2005 09:17:41 GMT
Trustin Lee wrote:

> 2005/11/15, Niklas Therning < 
> <>>:
>     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?

> I'll check in this change so you can see it more clearly.

Please do that. Maybe that will make me understand! :)


View raw message