directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <nik...@trillian.se>
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 <niklas@trillian.se 
> <mailto:niklas@trillian.se>>:
>
>     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! :)

/Niklas


Mime
View raw message