anchor.diff:  
   [cols="1a,1a", options="header"]
   |===
  -| CometD 4.0 | CometD 5.0
  +| CometD 4.0.x | CometD 5.0.x
   | `org.cometd.java:**bayeux-api**`
   | `org.cometd.java:**cometd-java-api-server**` (for server-side CometD applications) +
     `org.cometd.java:**cometd-java-api-client**` (for client-side only CometD applications)
  
positive.code: 
  [cols="1a,1a", options="header"]
  |===
  | CometD 4.0 | CometD 5.0
  | `org.cometd.annotation.AnnotationCometDServlet`
  | `org.cometd.annotation.**server**.AnnotationCometDServlet`
  
  
negative.code: |===
  
  [[_migration_30_to_31]]
  === Migrating from CometD 3.0.x to CometD 3.1.x
  
  Migration from CometD 3.0.x to CometD 3.1.x should be very easy, and most of the times just matter of updating the CometD version with no further changes to the application or the configuration.
  
  Below you can find the detailed list of the changes introduced in CometD 3.1.x.
  
  ==== API Behavior Changes
  
  The handshake operation will now throw an exception if executed multiple times without explicitly disconnecting in-between.
  
  Handshaking should be performed only once, and applications should enforce this by using once events such as `DOMContentLoaded`, or by guarding the handshake with a `boolean` field.
  For further information, see xref:_javascript_handshake[the JavaScript handshake section] or the xref:_java_client_handshake[the Java client handshake section].
  
  ==== Binary Data
  
  CometD now allows to send/receive messages with binary data, see xref:_concepts_binary_data[the binary data section].
  
  ==== Message Processing Order Changes
  
  The processing of incoming messages has slightly changed, affecting only writers of custom extensions (implementations of `BayeuxServer.Extension` or `ServerSession.Extension`).
  
  Previous behavior was to invoke `BayeuxServer.Extension.send(...)` and `ServerSession.Extension.send(...)` for both broadcast and service messages _before_ invoking the `ServerChannel.MessageListener` listeners.
  
  CometD 3.1.x behavior is to invoke `BayeuxServer.Extension.send(...)` and `ServerSession.Extension.send(...)` only for broadcast messages _after_ invoking the `ServerChannel.MessageListener` listeners.
  
  ==== HTTP/2 Support
  
  CometD applications are typically independent of the transport used to send or receive messages.
  
  However, if the transport is HTTP/2, CometD can be configured to take advantage of the HTTP/2 transport by removing the limit on the number of outstanding long polls, see the `http2MaxSessionsPerBrowser` parameter below.
  
  Where before a CometD applications opened in multiple browser tabs only had one tab performing the long poll (and all the other tabs performing a normal poll), now with HTTP/2 it is possible to remove this limitation and have all the tabs performing the long poll.
  
  ==== CometD Servlet Parameters Changes
  
  