一：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实现了这两个协议，并支持web
socket协议。
最新的浏览器（如火狐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中作为Cometd
Servlet的初始化参数来配置。
当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.Abstract
Service。它指定了服务器感兴趣的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 Baseball
TeamService 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.Server
AnnotationProcessor类。
@@依赖注入支持
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对象
相关文章
