make LocalChannel part of the SocketChannel hierarchy?

이희승 (Trustin Lee) trustin at gmail.com
Tue Aug 25 02:38:05 EDT 2009


On Mon, 17 Aug 2009 10:37:04 +0900 (KST)
이희승 (Trustin Lee) <trustin at gmail.com> wrote:

> Hi Iain,
> 
> On 08/15/2009 10:05 PM, Iain McGinniss wrote:
> > In my tests and code, I am often dealing with the SocketChannel  
> > related interfaces rather than concrete types, and it makes it
> > easier for me to use mock objects (either hand written, or produced
> > by jMock). As I writer higher and higher level tests, the burden
> > of mocking increases, to the point where I'd actually really like  
> > something that behaves like a real channel in every sense, but
> > does not necessarily use external resources that are difficult or
> > time consuming to clean up between test runs. LocalChannels would
> > fit this requirement nicely, but unfortunately they are not part of
> > the class hierarchy for the SocketChannel related types, despite
> > the fact that the LocalAddress objects that are used for addressing
> > extend SocketAddress.
> > 
> > I think it would be quite trivial to make all the classes in
> > question useable in my test cases, by doing the following:
> > 
> > 1. Make LocalChannel extend SocketChannel
> > 2. Make LocalServerChannel extend ServerSocketChannel
> > 3. Make LocalServerChannelFactory extend ServerSocketChannelFactory
> > 4. Make LocalClientChannelFactory extend ClientSocketChannelFactory
> > 
> > With these four changes, I believe the rest just falls into place,
> > as the LocalAddresses used are already subclasses of SocketChannel
> > and so the interfaces are compatible. This would then make it very
> > easy for me to test client-server interaction with worrying about
> > available ports on the test machine, and make setup / teardown very
> > easy and fast.
> > 
> > I can provide a patch for this, if others agree that this is a  
> > desirable change?
> 
> I like the idea.  However, I'd like to maintain the backward
> compatibility with the current API.  What do you think about writing a
> new transport based on the current local transport under
> org.jboss.netty.channel.socket.local?  As the local transport
> implementation is pretty simple and unlikely to change, I think
> copy-and-paste-and-modify is fine in this case.  LocalChannel could be
> renamed to LocalSocketChannel and so on.
> 
> Your contributor agreement has been approved.  Please go ahead and
> file a JIRA issue with a patch attached.  I'm looking forward to your
> contribution actually! :)

Here's the JIRA entry: https://jira.jboss.org/jira/browse/NETTY-212

Trustin



More information about the netty-users mailing list