On Sun, 16 Sep 2007 23:29:03 +0900 "Trustin Lee" <[EMAIL PROTECTED]> wrote:
> Hi, > > Today, I checked in a load of code that removed a lot of duplicate > code. Let me list the changes I've made: > > * Added IoProcessor interface > > This is a very thin reactor layer that provides abstract view over > various selector-style I/O processors. Very nice, actually for the APRConnector, I copy/pasted/cleaned SocketIOProcessor > > * AbstractIoFilterChain becomes DefaultIoFilterChain > > By removing duplicate doClose and doWrite implementations and using > IoProcessor interface, I was able to make AbstractIoFilterChain > non-abstract. All existing filter chain implementations have been > replaced with DefaultIoFilterChain. Nice, to see you changed it quickly :) > > * Added AbstractIoProcessor class > > This implements IoProcessor. Most part of the code has been extracted > from SocketIoProcessor, but should work fine with any selector-style > I/O processors. I wish Julien could experiment with this class to > implement APR transport. Anyway due to last trunk commit my APRIOProcessor is borked, so I'll need to digg into IoProcessor anyway. > > * Added NIOSession (extends AbstractIoSession) class > > DatagramSessionImpl and SocketSessionImpl extends it now to provide > common properties to NIOProcessor. > > * Replaced SocketIoProcessor with NIOProcessor > > NIOProcessor extends AbstractIoProcessor and implements all required > abstract methods. NIOProcessor can work with SocketChannels and > connected DatagramChannels. > > * DatagramConnector uses NIOProcessor > > Because NIOProcessor supports any kind of selectable ByteChannel, > connected datagram channels can be handled with NIOProcessore, too. > This also means DatagramConnector can be multi-threaded. Although I > didn't do that yet, it should be a piece of cake. > > On the other hand, an acceptor-side datagram channel has very > different communication style. I have no idea on how to reduce code > duplication in this case. Please let me know if you have any good > idea. > > I hope you like these changes, and I believe this refactoring will > help people other transports more easily. Any feed back is welcome! > > Trustin Well actually it broken my code, but I think it's for the good of MINA ;) Most of transport will probably share the IOProcessor model of the current NIO transport implementations. Perhaps I should push APRConnector out of my sandbox as soon as I resolved some issues. Julien
