Fix wording in "Interceptor Chain Pattern" section.
This commit is contained in:
parent
4ea375362f
commit
490fc249f8
@ -160,14 +160,14 @@
|
|||||||
<section>
|
<section>
|
||||||
<title>Event Model based on the Interceptor Chain Pattern</title>
|
<title>Event Model based on the Interceptor Chain Pattern</title>
|
||||||
<para>
|
<para>
|
||||||
Well-defined and extensible event model is a must for an event-driven
|
A well-defined and extensible event model is a must for an event-driven
|
||||||
application. Netty does have a well-defined event model focused on I/O.
|
application. Netty has a well-defined event model focused on I/O. It
|
||||||
It also allows you to implement your own event type without breaking the
|
also allows you to implement your own event type without breaking the
|
||||||
existing code at all because each event type is distinguished from
|
existing code because each event type is distinguished from another by
|
||||||
each other by strict type hierarchy. This is another differentiator
|
a strict type hierarchy. This is another differentiator against other
|
||||||
against other frameworks. Many NIO frameworks have no or very limited
|
frameworks. Many NIO frameworks have no or a very limited notion of an
|
||||||
notion of event model; they often break the existing code when you try
|
event model. If they offer extension at all, they often break the
|
||||||
to add a new custom event type, or just do not allow extension.
|
existing code when you try to add custom event types
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
A &ChannelEvent; is handled by a list of &ChannelHandler;s in a
|
A &ChannelEvent; is handled by a list of &ChannelHandler;s in a
|
||||||
@ -175,7 +175,7 @@
|
|||||||
<ulink url="http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html">Intercepting Filter</ulink>
|
<ulink url="http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html">Intercepting Filter</ulink>
|
||||||
pattern to give a user full control over how an event is handled and how
|
pattern to give a user full control over how an event is handled and how
|
||||||
the handlers in the pipeline interact with each other. For example,
|
the handlers in the pipeline interact with each other. For example,
|
||||||
you can define what to do when a data is read from a socket:
|
you can define what to do when data is read from a socket:
|
||||||
</para>
|
</para>
|
||||||
<programlisting>public class MyReadHandler implements &SimpleChannelHandler; {
|
<programlisting>public class MyReadHandler implements &SimpleChannelHandler; {
|
||||||
public void messageReceived(&ChannelHandlerContext; ctx, &MessageEvent; evt) {
|
public void messageReceived(&ChannelHandlerContext; ctx, &MessageEvent; evt) {
|
||||||
@ -188,8 +188,7 @@
|
|||||||
}
|
}
|
||||||
}</programlisting>
|
}</programlisting>
|
||||||
<para>
|
<para>
|
||||||
You can also define what to do when other handler requested a write
|
You can also define what to do when a handler receives a write request:
|
||||||
operation:
|
|
||||||
</para>
|
</para>
|
||||||
<programlisting>public class MyWriteHandler implements &SimpleChannelHandler; {
|
<programlisting>public class MyWriteHandler implements &SimpleChannelHandler; {
|
||||||
public void writeRequested(&ChannelHandlerContext; ctx, &MessageEvent; evt) {
|
public void writeRequested(&ChannelHandlerContext; ctx, &MessageEvent; evt) {
|
||||||
@ -202,7 +201,7 @@
|
|||||||
}
|
}
|
||||||
}</programlisting>
|
}</programlisting>
|
||||||
<para>
|
<para>
|
||||||
For more information about the event model, please refer to the
|
For more information on the event model, please refer to the
|
||||||
API documentation of &ChannelEvent; and &ChannelPipeline;.
|
API documentation of &ChannelEvent; and &ChannelPipeline;.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
Loading…
Reference in New Issue
Block a user