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
provided.
IoFilter.init() should either be changed into
void init( IoFilterChain parent, NextFilter nextFilter, IoSession
session ) throws Exception;
or
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?
/Niklas
