Author: Simone Bordet

A new feature that has been recently added to the upcoming CometD 2.1.0 release is
the support for annotated services, both on server side and on client side.

Services are the heart of a CometD application, because allow to write business logic that is executed when a message
arrives on a particular channel.
For example, in chat applications when a new member joins a chat room, the chat room’s members list is broadcasted to all
existing chat room members.

This is how an annotated service looks like:

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

    @PostConstruct
    public void init()
    {
        System.out.println("Echo Service Initialized");
    }

    @Listener("/echo")
    public void echo(ServerSession remote, ServerMessage.Mutable message)
    {
        String channel = message.getChannel();
        Object data = message.getData();
        remote.deliver(serverSession, channel, data, null);
    }
}

Annotations are great because they carry a semantic meaning to their annotation target.
Even if you have not written a CometD service before, the code above is pretty straightforward, and it is easy
to understand that the echo() method is invoked when a message arrives on the "/echo" channel.

Annotated services also reduce the amount of boilerplate code, especially on client side, where it is typical
to add listeners and subscribers as anonymous inner classes.

Compare:

bayeuxClient.getChannel(Channel.META_CONNECT).addListener(new ClientSessionChannel.MessageListener()
{
    public void onMessage(ClientSessionChannel channel, Message message)
    {
        // Connect handling...
    }
});

with:

@Listener(Channel.META_CONNECT)
public void metaConnect(Message connect)
{
    // Connect handling...
}

I find the second version much more readable, and since code is much more read than written, this is a fine improvement.

Lastly, CometD annotated services leverage the standard annotations for dependency injection and lifecycle management,
and therefore integrate nicely with Spring 3.x.

Take a look at the annotated services documentation
and to the CometD 2 Spring integration for details.

Enjoy !

The CometD project has finally released its 1.0 version !

I have already posted here about new features of the CometD project, but the 1.0 release is a further step forward in usability, stability and documentation.

For those of you that did not hear about the CometD project, it is a project that implements the Bayeux protocol to provide two-way seamless HTTP communication, from clients to server and from server to clients.

Any application that receives server-side events such as online games, online chats, online stock information, online sport results, online bet results, online content sharing, online social networking and so on is a potential perfect application that can use the libraries provided by the CometD project to greatly simplify development.

An event arrives on the server, and it is communicated to the clients with minimal latency via HTTP (and of course through firewalls, proxies, and more generally "through the web").

Such applications are generally dubbed as comet web applications (and you can read here who and when the term was coined).

The CometD project ships the following libraries to develop comet web applications:

• A JavaScript library, with bindings for the well known Dojo and jQuery toolkits
• A Java client library, to be used, for example, in rich Java clients such as Swing applications
• A Java server library, to be used to implement the logic behind you application

There are also alpha version of Perl and Python libraries, and you can find more implementations at this page.

Greg already blogged about the cool features of the CometD project, but I would like to emphasize how simple is to create your first comet web application with CometD, using Maven:

$ mvn archetype:generate -DarchetypeCatalog=http://cometd.org
...
$ mvn install jetty:run

Two lines, that’s it, and the detailed guidance of the CometD primer.
You don’t need to download and install anything, you can just start with the CometD primer, and you are ready.
After that, you can import the Maven project into your favorite IDE, and use the Jetty Plugin to develop-deploy instantaneously.

The documentation has much improved, and now covers the 3 major libraries shipped, in details.
Add to that How-Tos and FAQs, and a completely searchable website, so that you can enter your query (try "howtos") and have the documentation page that refers to your search.

Do you use Spring for your server side plumbing ?
There are detailed instructions of how to integrate with Spring.

The CometD project is a 1.0 release, but has already been deployed in many applications that range from few users to a potential of million of users, and proved to scale really well. No worries on this side, <shameless-plug>especially when you can have a company that backs you up</shameless-plug>.

Enjoy !

Many web applications are configured via web.xml.

Primary examples of this are Comet web application, which are configured via a ServletContextAttributeListener: you may want different listener classes depending on the enviroment you’re working in.

Another example is where Spring configuration files are provided via the contextConfigLocation context parameter.

Here I want to show how to do property substitution in web.xml based on Maven2 profiles.

Let’s start from the case where you don’t need property substitution.
These are your web.xml and pom.xml files:

// web.xml
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<listener>
<listener-class>com.acme.CometInitializer</listener-class>
</listener>
</webapp>
// pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<build>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.15</version>
<configuration>
<scanIntervalSeconds>10</scanIntervalSeconds>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>8080</port>
</connector>
</connectors>
<webAppConfig>
<contextPath>/</contextPath>
</webAppConfig>
</configuration>
</plugin>
</plugins>
</build>
</project>

As you can see, the pom.xml file specifies the Jetty plugin configuration, with no particular configuration needed: default values are good.
The web.xml file specifies a listener class that initializes your Comet web application.

Often times, however, you want your initializer to configure the application differently, for example by stubbing some functionality; as the initializer is complex, you write a different class.

At this point, you want to be able to specify a Maven2 profile that modifies the web.xml with the suitable class (default or stubbed).
Here’s how you do it:

// web.xml
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<listener>
<listener-class>${initializer.class}</listener-class> (1)
</listener>
</webapp>
// pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<build>
<resources> (2)
<resource>
<directory>${basedir}/src/main/resources</directory>
</resource>
<resource>
<directory>${basedir}/src/main/webapp/WEB-INF</directory>
<includes>
<include>web.xml</include>
</includes>
<filtering>true</filtering>
<targetPath>${project.build.directory}</targetPath>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.15</version>
<configuration>
<scanIntervalSeconds>10</scanIntervalSeconds>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>8080</port>
</connector>
</connectors>
<webXml>${project.build.directory}/web.xml</webXml> (3)
<webAppConfig>
<contextPath>/</contextPath>
</webAppConfig>
</configuration>
</plugin>
<plugin> (4)
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>${project.build.directory}/web.xml</webXml>
</configuration>
</plugin>
</plugins>
</build>
<profiles> (5)
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<filters>
<filter>${basedir}/src/main/filters/default.properties</filter>
</filters>
</build>
</profile>
<profile>
<id>stubs</id>
<build>
<filters>
<filter>${basedir}/src/main/filters/stubbed.properties</filter>
</filters>
</build>
</profile>
</profiles>
</project>
// default.properties
initializer.class=com.acme.CometInitializer
// stubbed.properties
initializer.class=com.acme.CometStubbedInitializer

Let’s review the changes step by step.

1. We replaced the listener class with a property in the web.xml file.
2. We added a resources section in the pom.xml file to reference both the standard resource location and the web.xml file.
   For the web.xml file we specified that the property-substituted version of the file must go in the standard maven output directory (by default ${basedir}/target, referenced as ${project.build.directory}).
3. We added the <webXml> element in the Jetty plugin configuration, referencing the property-substituted version of web.xml.
4. We added the configuration for the war plugin, so that building the war will reference the property-substituted version of web.xml.
5. We created two profiles that reference different filter files, which will contain the property values to be substituted. The standard Maven2 location for filter files is src/main/filters.

Now you can build your project as before by specifying the profile if you need the stubbed version, like this:

// Normal build
$ mvn clean install
// Stubbed build
$ mvn -Pstubbed clean install
// Stubbed build with Jetty plugin
$ mvn -Pstubbed jetty:run

Enjoy !