Typo, grammar, duplication ...

This commit is contained in:
Trustin Lee 2008-09-02 07:22:16 +00:00
parent b3c76b8cbf
commit fe7e2ea4bb
2 changed files with 10 additions and 11 deletions

View File

@ -27,16 +27,17 @@ import java.util.UUID;
/**
* A nexus to a network socket or a component which is capable of predefined
* I/O operations such as read, write, connect, and bind.
* A nexus to a network socket or a component which is capable of I/O
* operations such as read, write, connect, and bind.
* <p>
* A channel provides a user:
* <ul>
* <li>the current state of the channel,</li>
* <li>the configuration parameters of the channel,</li>
* <li>the I/O operations that the channel supports, and</li>
* <li>the current state of the channel (e.g. open, bound, and connected),</li>
* <li>the configuration parameters of the channel (e.g. receive buffer size),</li>
* <li>the I/O operations that the channel supports (e.g. read, write, connect, and bind), and</li>
* <li>the {@link ChannelPipeline} which handles all I/O events and requests
* associated with the channel.</li>
* associated with the channel. This is the most important place, where
* your application logic kicks into an action.</li>
* </ul>
*
* @author The Netty Project (netty-dev@lists.jboss.org)

View File

@ -35,9 +35,9 @@ import java.net.SocketAddress;
* For example, all I/O requests made by a user application are downstream
* events.
* <p>
* In most common use case of this interface is to intercept an I/O request
* The most common use case of this interface is to intercept an I/O request
* such as {@link Channel#write(Object)} and {@link Channel#close()}. The
* reveived {@link ChannelEvent} object is interpreted as described in the
* received {@link ChannelEvent} object is interpreted as described in the
* following table:
*
* <table border="1" cellspacing="0" cellpadding="6">
@ -104,9 +104,7 @@ import java.net.SocketAddress;
* {@link #handleDownstream(ChannelHandlerContext, ChannelEvent) handleDownstream}
* may be invoked by more than one thread simultaneously. If the handler
* accesses a shared resource or stores stateful information, you might need
* proper synchronization in the handler implementation. Also, please refer to
* the {@link ChannelPipelineCoverage} annotation to understand the
* relationship between a handler and its stateful properties.
* proper synchronization in the handler implementation.
* <p>
* Also, please refer to the {@link ChannelPipelineCoverage} annotation to
* understand the relationship between a handler and its stateful properties.