Hi,
Im just starting to have a look at this now - and I have a couple of
questions.
If you could help me in clearing them up that would be greatly
appreciated:
> Today we have SocketSessionManagerFilterChain,
DatagramSessionManagerFilterChain, and so on.
> This makes it hard to combine arbitrary IoFilterChains into longer
chains which is
> required for DIRMINA-121.
Agreed
> Add a new interface which is the counter part of IoHandler.
> I don't have a good name for it, let's call it IoProcessor for now.
> IoProcessor looks something like this:
> public interface IoProcessor {
> void write( IoSession session, WriteRequest writeRequest );
> void close( IoSession session, CloseFuture closeFuture ); }
The way I understand this is that the concrete "do a write / do a close"
behaviour used to be embedded in the concrete filter chain
implementations. E.g: SocketSessionManagerFilterChain knows how to do a
"real" write / close for a socket session. What we are doing here is
extracting this behaviour in to a sort of "strategy" interface which we
can plug in to any chain. Correct?
> Add some methods to the IoFilterChain interface:
> void setIoProcessor( IoProcessor p );
Makes sense if Im correct above. I.e: plug in the "processor" strategy
for the chain.
> void sessionOpened( IoSession session, IoHandler h ) throws Exception;
> void sessionClosed( IoSession session, IoHandler h ) throws Exception;
> void messageReceived( IoSession session, Object message, IoHandler h )
throws Exception; ...
> (I think you get the point)
Replacing the sessionOpened(IoSession) / sessionClosed(IoSession) et al
methods in AbstractFilterChain?
> These are exactly the same as the methods in IoHandler except that the
extra IoHandler argument has been added. > > The idea is that this
should be propagated through the chain (embedded in the NextFilter
class)
This is where my real question comes in: You say later that we shouldn't
need to refactor existing filter implementations.
How are we going to pass the handler through transparently without
changing the IoFilter / NextFilter interface?
I think this is the bit Im missing at the moment :o)
> When you call bind(address, chain, handler) the setIoProcessor()
method of the chain will be
> called to wire it up with the root filter chain owned by the
IoAcceptor/IoConnector.
Yep - plugging in its own strategy to the chain. Sounds good.
> I don't think it will require any refactoring of existing filters.
See question above
> It will also eliminate a couple of interface/classes (like the
SessionManagerFilterChains).
Cool! I love removing classes :o)
Cheers for your help,
Dave
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender. Thank you.
