Niklas Therning wrote:
...
Yes, setIoProcessor() isn't very nice, I agree. And I don't have a
solution for it except that copying the chain passed to setFilterChain()
into something like an IoProcessorAwareFilterChain. I can't see how the
above solves this. How does the wrapped chain know where to route
write() / close() calls? Or is it just to prevent setIoProcessor() from
being called?
I have a solution now! :)
I just realized that when calling IoSession.write() the concrete
IoSession implementation will always know the final destination of the
write event. For SocketSessionImpl the final destination is always
SocketIoProcessor.
So the IoFilterChain methods for downstream events look like this:
void write( IoSession session, WriteRequest writeRequest, IoProcessor p
) throws Exception;
SocketSessionImpl's write() method looks like this:
public WriteFuture write( Object message ) {
this.filterChain.write(this, new WriteRequest(),
SocketIoProcesso.getInstance());
}
Provided that SocketIoProcessor implements IoProcessor. I think you get
the point. The ChainedFilterChain will always know the next filter chain
to filter through and can wrap it in an
IoFilterChainToIoProcessorAdapter object.
Bottom line: setIoProcessor() WON'T BE NEEDED! This approach makes
IoFilterChain totally stateless which means the same filter chain can be
reused for different ports if the user wants that (though that would
probably not be advisable).
The only sacrifice I see right now is the IoFilterChain.getNextFilter()
methods. They would not return a proper NextFilter instance.
If it's ok with Dave I would like to see what he comes up with before we
abondon this approach. Dave, if you don't want to spend your time on
something that might get thrown away, please let me know and I can take
over.
/Niklas
