关于cometd的一些使用经验

关于cometd的一些使用经验
一：js端使用方式

===================================================
第一步 ：初始化cometd配置， 
            $.cometd.configure({
                url: cometdURL,
                logLevel: 'debug'
            });
有两种方式：
===================================================
一：经过 URL string
cometd.configure('http://localhost:8080/cometd');
二：经过配置对象的方式：
cometd.configure({
url: 'http://localhost:8080/cometd'
});
经过第二种方式配置cometd时，对象属性以下：
url：链接URL
logLevel：日志级别，默认为info，可支持warn、info、debug
maxConnections：客户端链接到cometd服务端最大链接数量，默认为2，根据浏览器的不一样，能够更改浏览器默认支持最大链接的相应值
backoffIncrement：与服务器链接失败后，等待重连的增量时间，默认为1000，单位为毫秒。如：第一次重连为1s，则第二次重连为2s之后，第三次3s，以此类推
maxBackoff：最大重连增量时间，默认为60000ms
reverseIncomingExtensions：
maxNetworkDelay：一个request请求链接服务器失败的最大等待时间，默认为10000ms
requestHeaders：request请求头，默认为｛｝
appendMessageTypeToURL：是否支持Bayeux消息类型能够被附加到URL上并发送至服务器，默认为true
autoBatch:当没有手动指定批次处理一批publish通信消息时，是否支持默认的批处理，默认为false


===================================================
第二步：调用 $.cometd.handshake()方法，与服务器通信握手
===================================================

调用configure后，并无启动Bayeux Communication，须要手动调用comted.handshake()进行通信握手，通信握手作了两件事情：
1.客户端与服务器协定通信协议类型
2.通信协议类型达成一致后，服务端通知客户端详细的请求时间

该方法是一个异步方法，在通信握手完成后会当即返回，可是handshake返回后并不表明链接已经创建，通信握手失败缘由可能有以下几个：
1.输错了访问的URL
2.客户端与服务器没有交换成功通信协议
3.服务器拒绝通信握手，例如：证书认证失败等
4.服务器down掉
5.网络传输失败
另外：cometd提供init()方法，集成了configure和handshake方法

因为handshake是异步的方法，你没法获知链接是否创建成功，即便创建成功，客户端也有可能被中断，例如服务器down机等缘由。cometd提供了监听机制，用来监听链接等特殊通道的状态

===================================================
第三步：订阅消息通道Channels，创建监听
subscribe 订阅普统统道消息、service通道消息
addListener 监听meta channels消息
===================================================
Bayeux 对Channels定义为：Channels相似于一个消息主题，有兴趣的人能够订阅该消息通道，并接收消息通道发布过来的消息。
Channels有三种：
1.meta channels(元数据channel，全部此种channel都以/meta开头)
2.service channels(服务channel，全部此种channel都以/service开头)
3.normal channels(普通channel)
每一个channel相似于一个目录的路径，例如/meta/connect
&& meta channels

meta channels是由Bayeux 协议自身创建的，开发时不能subscribe一个meta channel，不然服务器回响应错误的信息，可是你能够在meta channel上创建一个监听
向一个meta channels发送消息是毫无心义的，只有Bayeux协议建立并在meta channel上面传输信息
meta channels一般用在客户端监听错误信息上，例如：通信握手错误，网络链接错误等。


&& service channels
service channels 一般用在服务端与客户端request/response通信模式下，它与消息通知/订阅通信模式与普通channel大相径庭。
当订阅服务通道而且没有获得错误的响应时，此时服务端未处理任何操做，而且忽略了订阅请求。
你可使用一个服务器与客户端之间特定的语义，将消息发布到service channels。
service channels一般用来实现私聊。

&& normal channels
普通channels一般创建一个消息主题，并使用在publish/subscribe通信模式下。你能够在普通channel上进行订阅及消息发布。
普通channel一般用来向全部订阅的客户端发送主题消息，例如当股票价格发生波动的时候。

addListener()方法：
1.必须用在监听meta channels消息
2.可能会用在监听service channels消息，(也可使用subscribe（）方法，可是不被推荐使用)
3.不能用来监听normal channels消息，(通常使用subscribe（）方法来替代)
4.不能涉及任何与服务器的通信，这样能够在调用handshake（）以前调用。
5.是一个同步方法， 当它返回值时，必须保证listener已经添加。

subscribe()方法：
1.不能用在监听meta channels消息，不然服务器回返回错误。
2.可能会用在监听service channels消息，(也可使用addListener（）方法，推荐使用)
3.用来监听normal channels消息
4.包含于服务器的通信，在handshake被调用以前不能调用它
5.是一个异步的方法，在服务器收到并处理订阅请求以前当即返回。

注意：调用subscribe方法并不意味着当该方法返回值的时候你已经完成了服务器的订阅。
addListener和subscribe方法分别返回两个订阅对象能够传递给removeListener()和unsubscribe()方法。

// Some initialization code
var subscription1 = cometd.addListener('/meta/connect', function() { ... });
var subscription2 = cometd.subscribe('/foo/bar/', function() { ... });

// Some de-initialization code
cometd.unsubscribe(subscription2);
cometd.removeListener(subscription1);

/////////////////////////////////////
var _subscription;

// The idempotent method
function _refresh()
{
    _appUnsubscribe();
    _appSubscribe();
}

function _appUnsubscribe()
{
    if (_subscription) 
        cometd.unsubscribe(_subscription);
    _subscription = null;
}

function _appSubscribe()
{
    _subscription = cometd.subscribe('/foo/bar', function() { ... });
}
////////////////////////////////////////
值得注意的是，你要当心处理你的应用。为了不泄露函数调用或者避免函数屡次调用（一旦你屡次错误的绑定了相同的回调函数）
当服务器端未返回信息时（网络中断或者服务器crash时），subscribe和unsubscribe方法会有什么样的行为？
subscribe：本地监听者首先加入到channel中的订阅者列表中，而后与服务器通信。若是通信失败，服务器并不知道须要向客户端发送数据所以客户端本地的监听者并不会被反调。
unsubscribe：本地监听者首先从channel中断订阅者列表中移除。而后尝试与服务器通信。若是通信失败，服务器仍然发送信息到客户端，可是本地并无响应监听可指达。

关于监听者异常处理问题：
若是监听者/订阅者函数抛出异常，错误信息会以debug级别打印日志。然而，你能够定义一个全局异常监听处理函数来截获异常信息。
当监听者或者订阅者每次抛出异常时该全局方法都会被反调。
cometd.onListenerException = function(exception, subscriptionHandle, isListener, message)
{
    // Uh-oh, something went wrong, disable this listener/subscriber
    // Object "this" points to the CometD object
    if (isListener)
        this.removeListener(subscriptionHandle);
    else
        this.unsubscribe(subscriptionHandle);
}
全局异常监听机制可能会向服务端发送消息。若是异常监听处理函数抛出了异常，异常会以info级别的日志形式
打印出来，Cometd框架不会break掉。

////////////////////////////////////
使用通配符能够同时订阅多个渠道，例如：
cometd.subscribe("/chatrooms/*", function(message) { ... });
单个星号统配单一渠道段，如：/chatrooms/12 /chatrooms/15 不支持/chatrooms/12/upload
为了统配多渠道段，可使用双星号，如：
cometd.subscribe("/events/**", function(message) { ... });
使用多渠道可支持相似/events/12/upload events/12 events/12/upload/abc等通道
通配符原理一样应用在监听者中，例如：
cometd.addListener("/meta/*", function(message) { ... });
默认的，订阅总体通配符/*和/**会发生错误，通配符只能放在分段的最后面。

目前为止最有趣的meta channels 是 /meta/connect，由于服务器能够返回当前链接的状态。
值得一提的是,meta/connect也被用于长轮询服务器。所以，若是在一个有效的轮询中发布一个断开消息，
服务器会返回该poll并触发/meta/connect linstener。


=============================================================
第四步 调用publish方法向通道中发布消息
=============================================================
publish方法容许你向某一特定的channel中发布消息
cometd.publish('/mychannel', { mydata: { foo: 'bar' } });
不能发布消息到meta channel，可是能够发布消息到一个未订阅的channel，前提是你已经handshake了
publish是一个异步的通信方法，在服务器收到消息以前它会当即返回。

=============================================================
关于disconnecting
=============================================================
cometd js api提供了自动重连功能当网络或服务器链接失败时。重连参数在configuration中配置

1.短暂网络链接失败
一旦发生网络暂时链接失败，客户端会经过/meta/connect通道发布消息，并将successful标志位置为false。
此时服务器会保持客户端的状态，一旦网络回复链接，服务器会恢复链接就像未发生中断同样。
客户端在这种状况下，仅仅须要从新创建长轮询，可是在网络中断期间发布给服务器的消息不会被重发。
2.长时间网络异常或服务器异常
若是网络链接长时间异常，服务器将会超时并失去客户端链接，并删除与之相关的状态。
在这种状况下，客户端的重连机制将会执行如下步骤：
。。长轮询试图从新创建，可是服务器拒绝访问并返回402：：Unknown client错误信息
。。通信握手试图从新创建，服务器一般会接收，并从新创建一个链接
。。在通信握手创建成功的基础上，长链接从新创建。


若是注册了meta channels，了解这些步骤，由于从新链接可能会涉及多个服务器的消息交换。


调用disconnect函数致使消息被发送给Bayeux服务端，以便服务端清理关于该客户端的状态维护。
正如全部涉及到与服务器通信的方法同样，它是一个异步的方法。若是服务器并未返回，js端将会中止全部的试图的链接，而且清理本地状态。
无论disconnect方法返回成功或者失败，该方法都是安全的。客户端不管如何都会disconnect，它的本地状态会被清理掉。
若是服务器没有返回值，最终该客户端将会被超时处理，而且清理服务端的状态。


=============================================================
关于message bantching
=============================================================
咱们常常须要向服务器不一样的渠道同时发送数据。因为publish方法是异步的，同时向服务器端发布屡次时，并不能一块儿发布并依次返回。
咱们曾天真的这样处理：
cometd.handshake();

// Warning: non-optimal code
cometd.publish('/channel1', { product: 'foo' });
cometd.publish('/channel2', { notificationType: 'all' });
cometd.publish('/channel3', { update: false });
你可能认为，三个publish方法会相继的从客户端发出，可是实际并不是如此。publish方法是异步的，它会当即返回值。所以3个publish方法可能在未返回任何数据以前到达网络。
以上发生的是，第一个publish方法会当即执行，另外两个放入队列中，等待第一个publish执行完成。
当服务端接收到publish发送过来的消息时，第一个publish执行完成，服务器返回meta信息给客户端。客户端接收该信息并完成publish方法。
当第一个publish完成后，第二个被执行并等待完成，以后第三个被执行。

若是configuration参数autoBatch设置为true，应用程序会自动执行批次里面已排队的消息。
所以，在上面的例子中，若是autoBatch设置了true，第一个publish方法会当即被执行，当它执行完成后，
应用程序会将第二个和第三个publish打包成一个请求发送到服务器。
这种排队机制是为了不在长轮询后面发起publish队列，若是没有这个机制，浏览器会受到3个发布请求，可是只能有2个连接，
一个是已经被占用的长轮询请求。所以浏览器可能会决定循环发送request，因此第一个publish发生在第二个链接中（第一个已经
忙于长轮询请求），调度第二个publish使用第一个链接，第三个publish使用第二个链接，当第一个publish返回后。
结果是，若是你有一个超时时间为5分钟的长链接，第二个publish请求可能比第一个和第三个publish晚5分钟到达服务器。
你可使用batching优化这三个publish请求，经过将消息绑定成组造成一个单一的Bayeux消息。

cometd.handshake();

cometd.batch(function()
{
    cometd.publish('/channel1', { product: 'foo' });
    cometd.publish('/channel2', { notificationType: 'all' });
    cometd.publish('/channel3', { update: false });
});

// Alternatively, but not recommended
cometd.startBatch()
cometd.publish('/channel1', { product: 'foo' });
cometd.publish('/channel2', { notificationType: 'all' });
cometd.publish('/channel3', { update: false });
cometd.endBatch()

当一个batch启动后，随后的API调用将再也不发送到服务器，而是会排队等候，直到batch结束。
batch将全部的排队等候的message包装成单一的一个Bayeux消息并发送至Bayeux服务器。
消息绑定有效的利用了网络，将三个request/response生命周期缩短成一个。

=============================================================
关于transports
=============================================================
Bayeux规范定义了两个强制性的传输协议：
long-polling和callbak-polling
cometd实现了这两个协议，并支持websocket协议。
最新的浏览器（如火狐3.5+），也有可能使用长轮询通讯及跨站点通信。

1.long-polling transport
long-polling transport是浏览器和服务器之间默认的通信协议，若是不支持websocket的话。
该协议应用在跨域名及相同域名的客户端、服务器通信。数据类型被组织成text/json格式并经过一个普通的XMLHttpRequest推送至服务器。
2.callback-polling transport
callback-polling transport应用在跨域名通信。众所周知，XMLHttpRequest访问不一样域中的脚本是有限制的。







二 java端

=========================
基本概念
=========================
Cometd java端的实现创建在流行的jetty http服务器及servlet容器上。尽管它基于jetty，可是
它也能够简便的移植到其余2.5及以上的servlet容器（由于它使用了便携式的jetty continuation api）。
使用了cometd的war包能够部署到除jetty外的其余servlet2.5容器上，可是应用较少，由于它会减弱与servlet的集成。
当部署在servlet3.0容器上时，cometd app将会使用servlet容器提供的异步特性。并具备充分的便携性及高扩展性。
cometd java实现提供了一个客户端包和服务端包。

java cometd 基本概念
comtd技术使用Bayeux协议提供的可伸缩的基于HTTP通信的消息传递来实现。
通常来讲，消息系统是经过一个网络协议通信的客户端和服务端组成。这种捕获模式成为半对象加协议。

Sessions
Client-session是表明与Bayeux服务器通信会话的客户端的一半对象。客户端创建session对象后，最初与服务端的SeverSession并没有关联。
只有当客户端session与服务端通信握手，此时建立响应的服务器会话，并建立两个半对象之间的关系。
client-session对象直接指向远程的客户端，但它也一样存在于服务端。Bayeux服务器只知道server session半对象，惟一建立server Session办对象的途径是首先创建它的客户端session通信者，并经过server通信握手。
为此，在服务端有一个附加的概念：LocalSession。它集成自ClientSession。LocalSession是一个存在于服务端的client Session，它是服务端本地的对象。
例如：服务端的services与local session关联在一块儿。在服务端service创建以前，local session进行通信握手并创server session半对象通信服务。所以Bayeux服务端能够经过ServerSession以一样的方式处理远程的session和local session。
在cometd中，两个半对象经过交换信息来通信。

message
java api提供了服务端的消息接口，用来进行只读信息的交互。
用户能够修改消息内容，Message的内置子接口Mutable经过回调函数的参数使用。
在服务端，内置接口ServerMessage容许信息只读的交互，Mutable内置接口被做为回调函数的参数传送。
message被用来在channel里面传送。

channel
channel被定义为消息的主题，消息能够发送给全部订阅该主题并可接收主题信息的人。
在服务端，ServerChannel子接口容许与channel进行交互，例如经过发布消息或者增长监听者。

=================================
cometd java 服务端配置
=================================
BayeuxServer和服务传输协议参数能够在web.xml中做为CometdServlet的初始化参数来配置。
当CometD servlet建立了BayeuxServer实例后，servlet的初始化参数会经过BayeuxServer实例转变成服务传输协议配置。
ComtedServlet必须在web.xml里配置，不然服务器不能使用Bayeux协议。一般将路径配置成/cometd/*，可是能够更改url-pattern路径。

BayeuxServer 配置文件

logLevel          默认0     0=off 1=config 2=info 3=debug
transports        默认空    以逗号分隔的ServerTransport实现类，这些实现类新增至默认的server transport上
allowedTransports 默认空    以逗号分隔的能够容许使用的ServerTransports实现类，若是未特殊说明，默认的通信将被容许。

Server Transport Configuration
cometd 2中，服务协议能够经过插件化参数的形式配置，它可使用指定的前缀来配置不一样的协议参数。
例如，timeout参数没有任何前缀，所以它对全部的协议都有效，long-polling.jsonp.timeout参数重写了timeout参数，该参数对callback polling协议有用。

timeout    默认：30000ms  服务器将空数据包响应至一个长轮询前等待接收消息的最大时间
ws.timeout 默认：15000ms  相似于timeout参数，仅对websocket协议生效
interval   默认：0ms  指定客户端在一个长轮询结束到下一个长轮询开始之间的等待时间
ws.interval默认：2500ms相似于interval,仅对websocket协议生效
maxInterval默认：10000ms在客户端被认为失效及离开以前，服务端等待客户端长轮询的最大时间
ws.maxInterval  默认：15000ms 相似于maxInterval，仅对websocket生效
maxLazyTimeout  默认：5000ms  服务器等待lazy消息发布的最大时间
metaConnectDeliverOnly 默认：false 传输协议是否只能经过long poll方式传递信息
jsonDebug 默认：false 是否打开debug
maxSessionsPerBrowser 默认：1  每一个浏览器可容许的最大session数量，
allowMultiSessionsNoBrowser 默认：false 当浏览器未被检测到时是否容许多个Sessions
multiSessionInterval 默认：2000

Advanced Configuration
若果你使用的是jetty 7,你可能会想配置CrossOriginFilter
跨站脚本访问

Authorization（身份认证）
Bayeux对象能够被配置在SecurityPolicy对象中，SecurityPolicy对象容许控制Bayeux协议的各个步骤。例如handshake、subscription、publish等
默认状况下，Bayeux对象没有被配置到SecurityPolicy，这意味着任何操做都是通过受权的。
SecurityPolicy 有一个默认的实现对象DefaultSecurityPolicy，它可做为一个基类用于定制安全权限。

SecurityPolicy 的方法有:

boolean canHandshake(BayeuxServer server, ServerSession session, ServerMessage message);

boolean canCreate(BayeuxServer server, ServerSession session, String channelId, ServerMessage message);

boolean canSubscribe(BayeuxServer server, ServerSession session, ServerChannel channel, ServerMessage messsage);

boolean canPublish(BayeuxServer server, ServerSession session, ServerChannel channel, ServerMessage messsage);

DefaultSecurityPolicy 实现了：
1.容许任何handshake
2.容许建立除meta channel以外的任何由客户端发送通信握手过来的channel。
3.可进行任何由客户端handshake过来的订阅，除meta channel以外
4.容许publish 除meta channel

Authorizers（受权者）
Authorizers 实现了Autorizer，并在服务端启动时添加到channel中。此时channel并未发生任何操做。
Authorizers很是适合用来控制channel在启动时进行身份认证,或者在运行时创建从新创建ID的channel。
Autorizers不支持meta channel,可是能够被添加到一个带有通配符的channel中，并能够影响全部符合的通配channel。
一个Autorizers添加到/**上，会影响全部的channel。对非通配的，会做用到父级，如：/chat/room/10上添加受权者，也会做用于/chat/room/* /chat/room/** /chat/** /**


=================================
mutiple sessions
=================================
HTTP 协议推荐每一个域最多有两个connect链接。虽然如今浏览器默认配置没两个域有两个以上的链接，
可是这样作是不安全的，所以任何的iframe，标签或者窗口在同一个浏览器链接到同一主机时须要共享两个链接。
若是两个iframe/tabs/windows启动了一个Bayeux通信，都将开始一个长轮询链接请求，而且两个链接都被消耗掉，使得其它的Bayeux请求没法被传送，直到其中的长轮询结束。


================================
服务端 service
================================
CometD服务是一个java类，它容许开发者指定当贝叶消息到达贝叶通道时运行的代码块。
消息到达一个已订阅通道的服务器实例，回调方法将被调用执行用户特定的代码。
Cometd 2 服务有两种：继承和注解。

1.继承
Cometd继承服务实现自org.cometd.server.AbstractService。它指定了服务器感兴趣的Bayeux通道，

public class EchoService extends AbstractService //继承   AbstractService                             
{
    public EchoService(BayeuxServer bayeuxServer)                                 
    {
        super(bayeuxServer, "echo");      //经过BayeuxServer对象和服务通道名称调用父类构造                                        
        addService("/echo", "processEcho");    //订阅echo通道， 并指定消息到达通道时的回调函数                                  
    }

    public void processEcho(ServerSession remote, Map<String, Object> data) //定义回调函数
    {
        remote.deliver(getServerSession(), "/echo", data, null); //使用ServerSessionAPI将消息返回给特定的客户端
    }
}

这是一个简单的echo服务，远程的客户端经过echo通道将数据返回给远程的客户端自己。
BayeuxService须要回调函数至少实现如下方法中的一个：

// 获取远程session对象及消息对象
public void processEcho(ServerSession remote, Message message)

//获取远程session对象，以及消息对象的Map形式
// 附加的消息信息，例如当通道或id丢失的时候
public void processEcho(ServerSession remote, Map<String, Object> data)

//得到远程session对象，channel名称，消息对象，消息id
public void processEcho(ServerSession remote, String channelName, Message message, String messageId)

//得到远程session对象，channel名称，消息对象map形式，消息id
public void processEcho(ServerSession remote, String channelName, Map<String, Object> data, String messageId)

既然chanel名称能够在subscribe()中指定，而且能够应用通配，如：
public class BaseballTeamService extends AbstractService
{
    public BaseballTeamService(BayeuxServer bayeux)
    {
        super(bayeux, "baseballTeam");
        addService("/baseball/team/*", "processBaseballTeam");
    }

    public void processBaseballTeam(ServerSession remote, String channelName, Map<String, Object> data, String messageId)
    {
        // Upon receiving a message on channel /baseball/team/*, forward to channel /events/baseball/team/*
        //接收/baseball/team/*的消息，并发布至/events/baseball/team/*通道
        getBayeux().getChannel("/events" + channelName).publish(getServerSession(), data, null);
    }
}

在示例代码中，咱们经过调用deliver（）方法对一个指定的远程客户单发送消息，使用publish方法对订阅了某一通道的全部客户端发送消息。


2.注解
从Cometd2.1.0开始支持注解
经过@Service标注的类做为标注服务，可使用在客户端和服务端。

-----------------
服务端注解服务
-----------------
服务器端的cometd一般用AbstractServer实现类来实现，这些类的实例一般是一个单例模式，而且在web app配置并在启动的时候建立。
AbstractServer对可用的服务端功能实现、与serverSession访问相关联、使用服务实例注册、消息回调等功能提供较少的方法。
一个服务可能依赖于其余的服务，而且可能须要管理生命周期，例如在适当的时候可能须要调用服务的start()或stop()方法。
在继承AbstractService这种实现方式上，依赖注入和生命周期的管理须要手动在servlet或者监听者里面配置。

服务端经过注解方式实现的服务对Cometd产品特色提供了完美的支持。而且有限的支持依赖注入和生命周期管理经过org.cometd.annotation.ServerAnnotationProcessor类。

@@依赖注入支持
Comted工程提供了有限的依赖注入支持，由于这一般经过其余框架实现，例如spring或guice。
尤为是，它近支持了注入BayeuxServer对象的fields和methods。而且依赖注入仅在未执行的状况下执行一次。

如：
@org.cometd.annotation.Service("echoService")//使用@Service注解server类，并指定server名为“echoService”
public class EchoService
{
    @javax.inject.Inject//经过标准的JSR 330注解field
    private BayeuxServer bayeux;
}

@Inject注入被听从JSR330标准的依赖注入容器所支持，如Spring3.x。


@@生命周期管理支持
Cometd 工程经过JSR 250 @PostConstruct and @PreDestroy标准 提供了生命周期管理注解。
这对于那些不适用依赖注入容器来管理生命周期的如spring提供支持。


@@通道配置支持
为了在chanel被实际订阅以前初始化，Comted API提供了BayeuxServer.createIfAbsent方法，它能够经过参数配置给定的channel
此外，在任何订阅或者监听者添加以前配置channel这一步骤很是的有用，例如在channel上配置受权人。
在注解服务内，咱们可使用@Configure注解方法，如：
@Service("echoService")
public class EchoService
{
    @Inject
    private BayeuxServer bayeux;

    @Configure("/echo")
    public void configure(ConfigurableServerChannel channel)
    {
        channel.setLazy(true);
        channel.addAuthorizer(GrantAuthorizer.GRANT_PUBLISH);
    }
}


@@Session 配置支持
继承AbstractServer的服务有两个方便反而方法访问LocalSession和ServerSession，方法名分别是
getLocalSession()和getServerSession()。

@Service("echoService")
public class EchoService
{
    @Inject
    private BayeuxServer bayeux;

    @org.cometd.annotation.Session
    private LocalSession localSession;

    @org.cometd.annotation.Session
    private ServerSession serverSession;
}

@session注解的域是可选的。咱们能够仅仅使用LocalSession field，或者两个，或者都不使用。这取决于你是否须要他们。
Session域或者方法不能被@Inject标注。由于LocalSession和ServerSession是有关联的，而且绑定一个特殊的服务实例。
使用普通的注入机制会致使程序混乱。


@@监听着配置支持
对服务端来讲，使用@Listener注解方法表示回调在服务端处理的消息调用的回调过程。
监听者消息经过得到SeverSession半对象的引用来发送消息，而且经过ServerMessage对server加工。

@Service("echoService")
public class EchoService
{
    @Inject
    private BayeuxServer bayeux;
    @Session
    private ServerSession serverSession;

    @org.cometd.annotation.Listener("/echo")
    public void echo(ServerSession remote, ServerMessage.Mutable message)
    {
        String channel = message.getChannel();
        Object data = message.getData();
        remote.deliver(serverSession, channel, data, null);
    }
}
回调函数可能会返回false指明随后的监听者不该该被执行而且消息不会被publish

@@支持订阅配置
对服务端来讲，使用@Subscription标注的方法表示本地端处理消息时的回调函数
本地处理等同于远程客户端处理，不是服务端本地。
语义很是相似于远程客户端的处理，就意义而言，消息在服务端处理完毕后将会被发布，当它到达另外一端时发布者将不可用。
所以消息将被载入Message对象中，而非ServerMessage中.

@@注解处理
cometd注解处理类为ServerAnnotationProcessor 

BayeuxServer bayeux = ...;

// Create the ServerAnnotationProcessor
ServerAnnotationProcessor processor = new ServerAnnotationProcessor(bayeux);

// Create the service instance
EchoService service = new EchoService();

// Process the annotated service
processor.process(service);

当process方法返回以后，服务器经过调用初始化生命周期方法以及注册监听者和订阅者已经处理完标注的BayeuxServer对象以及session对象

查看更多