2005/11/17, Niklas Therning <[EMAIL PROTECTED]>:
Actually, there is IoFilterChain.getParent() so you can get IoSession. :)
But I love the first option because it makes a user to implement his or her init / destroy() method.
SSLFilter start SSL handshake as soon as it is added to the chain, so it requires NextFilter.
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;
Actually, there is IoFilterChain.getParent() so you can get IoSession. :)
But I love the first option because it makes a user to implement his or her init / destroy() method.
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?
SSLFilter start SSL handshake as soon as it is added to the chain, so it requires NextFilter.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
