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
(Please forgive me if this is the second time you get this mail. My
outgoing mail server seems to have some problems today.)
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
