Recreating the chains on every invocation sounds like a very expensive price to pay on every call. What is exactly the benefit we will be getting out of it?
> -----Original Message----- > From: Niklas Therning [mailto:[EMAIL PROTECTED] > Sent: 14 November 2005 20:42 > To: Apache Directory Developers List > Subject: Re: [mina] IoFilters: DIRMINA-121 / 122 > > Irving, Dave wrote: > > >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? > > > > > > > Absolutely 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? > > > > > Yes. > > > > > > >>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) > > > > > > > And that's where things get really tricky! ;-) Actually when I have a > look at the code now I see that the concrete NextFilter instances are > created only once and then used all the time. If my idea is going to > work the NextFilter objects created by AbstractIoFilterChain will have > to be created on each filter invocation. We need a new NextFilter > implementation. Here's an example: > > public static class UpstreamNextFilter implements NextFilter { > Entry head; > IoHandler handler; > public UpstreamNextFilter(Entry head, IoHandler handler) { > this.head = head; > this.handler = handler; > } > public void sessionCreated( IoSession session ) > { > if (head != null) { > head.filter.sessionCreated(new > UpstreamNextFilter(head.nextEntry, handler), session); > } else { > handler.sessionCreated(session); > } > } > public void sessionOpened( IoSession session ) > { > if (head != null) { > head.filter.sessionOpened(new > UpstreamNextFilter(head.nextEntry, handler), session); > } else { > handler.sessionOpened(session); > } > } > public void sessionClosed( IoSession session ) > { > if (head != null) { > head.filter.sessionClosed(new > UpstreamNextFilter(head.nextEntry, handler), session); > } else { > handler.sessionClosed(session); > } > } > ... (I think you get the point) > > In AbstractIoFilterChain sessionCreated() would look something like: > > public void sessionCreated( IoSession session, IoHandler handler ) > { > Entry head = this.head; > new UpstreamNextFilter(head, handler).sessionCreated(session); > } > > There would also be a corresponding DownstreamNextFilter implementation > (perhaps Upstream and Downstream can be combined into one) which takes > an IoProcessor in its constructor instead of an IoHandler. > > One thing that strikes me now is that the NextFilter interface is almost > the union of IoHandler and IoProcessor. Except that the methods of > NextFilter aren't allowed to throw Exception. Maybe that fact could be > used to simplify the API? > > I hope this made any sense. It works in my head but that doesn't have to > mean anything! ;-) > > /Niklas
