368156f5d0
- Channel now creates a ChannelPipeline by itself I find no reason to allow a user to use one's own pipeline implementation since I saw nobody does except for the cases where a user wants to add a user attribute to a channel, which is now covered by AttributeMap. - Removed ChannelEvent and its subtypes because they are replaced by direct method invocation. - Replaced ChannelSink with Channel.unsafe() - Various getter renaming (e.g. Channel.getId() -> Channel.id()) - Added ChannelHandlerInvoker interface - Implemented AbstractChannel and AbstractServerChannel - Some other changes I don't remember
137 lines
5.1 KiB
Java
137 lines
5.1 KiB
Java
/*
|
|
* Copyright 2011 The Netty Project
|
|
*
|
|
* The Netty Project licenses this file to you under the Apache License,
|
|
* version 2.0 (the "License"); you may not use this file except in compliance
|
|
* with the License. You may obtain a copy of the License at:
|
|
*
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
*
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
* License for the specific language governing permissions and limitations
|
|
* under the License.
|
|
*/
|
|
package io.netty.channel;
|
|
|
|
|
|
import io.netty.util.AttributeMap;
|
|
|
|
/**
|
|
* Enables a {@link ChannelHandler} to interact with its {@link ChannelPipeline}
|
|
* and other handlers. A handler can send a {@link ChannelEvent} upstream or
|
|
* downstream, modify the {@link ChannelPipeline} it belongs to dynamically.
|
|
*
|
|
* <h3>Sending an event</h3>
|
|
*
|
|
* You can send or forward a {@link ChannelEvent} to the closest handler in the
|
|
* same {@link ChannelPipeline} by calling {@link #sendUpstream(ChannelEvent)}
|
|
* or {@link #sendDownstream(ChannelEvent)}. Please refer to
|
|
* {@link ChannelPipeline} to understand how an event flows.
|
|
*
|
|
* <h3>Modifying a pipeline</h3>
|
|
*
|
|
* You can get the {@link ChannelPipeline} your handler belongs to by calling
|
|
* {@link #getPipeline()}. A non-trivial application could insert, remove, or
|
|
* replace handlers in the pipeline dynamically in runtime.
|
|
*
|
|
* <h3>Retrieving for later use</h3>
|
|
*
|
|
* You can keep the {@link ChannelHandlerContext} for later use, such as
|
|
* triggering an event outside the handler methods, even from a different thread.
|
|
* <pre>
|
|
* public class MyHandler extends {@link SimpleChannelHandler}
|
|
* implements {@link LifeCycleAwareChannelHandler} {
|
|
*
|
|
* <b>private {@link ChannelHandlerContext} ctx;</b>
|
|
*
|
|
* public void beforeAdd({@link ChannelHandlerContext} ctx) {
|
|
* <b>this.ctx = ctx;</b>
|
|
* }
|
|
*
|
|
* public void login(String username, password) {
|
|
* {@link Channels}.write(
|
|
* <b>this.ctx</b>,
|
|
* {@link Channels}.succeededFuture(<b>this.ctx.getChannel()</b>),
|
|
* new LoginMessage(username, password));
|
|
* }
|
|
* ...
|
|
* }
|
|
* </pre>
|
|
*
|
|
* <h3>Storing stateful information</h3>
|
|
*
|
|
* {@link #setAttachment(Object)} and {@link #getAttachment()} allow you to
|
|
* store and access stateful information that is related with a handler and its
|
|
* context. Please refer to {@link ChannelHandler} to learn various recommended
|
|
* ways to manage stateful information.
|
|
*
|
|
* <h3>A handler can have more than one context</h3>
|
|
*
|
|
* Please note that a {@link ChannelHandler} instance can be added to more than
|
|
* one {@link ChannelPipeline}. It means a single {@link ChannelHandler}
|
|
* instance can have more than one {@link ChannelHandlerContext} and therefore
|
|
* the single instance can be invoked with different
|
|
* {@link ChannelHandlerContext}s if it is added to one or more
|
|
* {@link ChannelPipeline}s more than once.
|
|
* <p>
|
|
* For example, the following handler will have as many independent attachments
|
|
* as how many times it is added to pipelines, regardless if it is added to the
|
|
* same pipeline multiple times or added to different pipelines multiple times:
|
|
* <pre>
|
|
* public class FactorialHandler extends {@link SimpleChannelHandler} {
|
|
*
|
|
* // This handler will receive a sequence of increasing integers starting
|
|
* // from 1.
|
|
* {@code @Override}
|
|
* public void messageReceived({@link ChannelHandlerContext} ctx, {@link MessageEvent} evt) {
|
|
* Integer a = (Integer) ctx.getAttachment();
|
|
* Integer b = (Integer) evt.getMessage();
|
|
*
|
|
* if (a == null) {
|
|
* a = 1;
|
|
* }
|
|
*
|
|
* ctx.setAttachment(Integer.valueOf(a * b));
|
|
* }
|
|
* }
|
|
*
|
|
* // Different context objects are given to "f1", "f2", "f3", and "f4" even if
|
|
* // they refer to the same handler instance. Because the FactorialHandler
|
|
* // stores its state in a context object (as an attachment), the factorial is
|
|
* // calculated correctly 4 times once the two pipelines (p1 and p2) are active.
|
|
* FactorialHandler fh = new FactorialHandler();
|
|
*
|
|
* {@link ChannelPipeline} p1 = {@link Channels}.pipeline();
|
|
* p1.addLast("f1", fh);
|
|
* p1.addLast("f2", fh);
|
|
*
|
|
* {@link ChannelPipeline} p2 = {@link Channels}.pipeline();
|
|
* p2.addLast("f3", fh);
|
|
* p2.addLast("f4", fh);
|
|
* </pre>
|
|
*
|
|
* <h3>Additional resources worth reading</h3>
|
|
* <p>
|
|
* Please refer to the {@link ChannelHandler}, {@link ChannelEvent}, and
|
|
* {@link ChannelPipeline} to find out what a upstream event and a downstream
|
|
* event are, what fundamental differences they have, how they flow in a
|
|
* pipeline, and how to handle the event in your application.
|
|
* @apiviz.owns io.netty.channel.ChannelHandler
|
|
*/
|
|
public interface ChannelHandlerContext extends AttributeMap, ChannelHandlerInvoker {
|
|
Channel channel();
|
|
ChannelPipeline pipeline();
|
|
|
|
String name();
|
|
ChannelHandler handler();
|
|
|
|
boolean canHandleInbound();
|
|
boolean canHandleOutbound();
|
|
|
|
ChannelFuture newFuture();
|
|
ChannelFuture newSucceededFuture();
|
|
ChannelFuture newFailedFuture(Throwable cause);
|
|
}
|