directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <>
Subject Re: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 12:03:15 GMT
Irving, Dave wrote:

>>One thing that has struck me is that it might actually be more
>intuitive from a user perspective 
>>that session.getFilterChain() always returns the entire chain for the
>user to modify. But maybe that's just me.
>I agree. The proposed "smart-NextFilter" approach and the simple
>building per session approach would do exactly this: The user always
>sees the whole "logical" chain which applies to their session
Another thing just struck me. The NextFilter given to the filter in 
IoFilter.init() is (as far as I can see) useless to the filter. There's 
no use for a NextFilter unless you have an IoSession.  You can't fire an 
asynchronous event on the NextFilter instance specified in init() unless 
you have a session as well. And whenever an IoFilter is given to an 
IoSession (messageReceived, sessionOpened, etc) a NextFilter is also 

IoFilter.init() should either be changed into

void init( IoFilterChain parent, NextFilter nextFilter, IoSession 
session ) throws Exception;


void init( IoFilterChain parent ) throws Exception;

The first option would mean that you can't call init() on a filter until 
it is actually in use for a particular session which means that the 
chain can not be constructed until a session has been created. Second 
option means you can't get hold of a NextFilter for asynchronous events 
until another event has been generated on a particular session in the 
usual way.

Does anyone else see this is or am I just being stupid? :) Is anyone 
using the NextFilter provided in init() and can prove me wrong?


View raw message