Jean-Francois Arcand's Blog

Jean-Francois Arcand has worked for Sun Microsystems since 2000. He currently works on GlassFish, mainly on the WebContainer and the new Java NIO based http engine called Grizzly. Before joining Sun, he has worked as a software architect for compagnies such as France Telecom, Microcell Telecom and HMS Software, in both Java and C++. Jean-Francois lives and works from home in Prevost, a very small city in Quebec where life is perfect.

Finally a portable implementation! The Bayeux protocol now supported by the Atmosphere Framework

The work done by the Cometd team, the java implementation of the Bayeux Protocol, can now run on top of the Atmosphere Framework. Under the hood, the proper Comet API is as usual detected!

The default implementation uses Jetty 7 Continuation under the hood...but now if you run it on top of the Atmosphere Framework, it will auto detect the container's native Comet API (or use the Servlet 3.0 async if available)! So you can now run the same application using GlassFish, Tomcat 5/6, Jetty 6, WebLogic, JBossWeb and event Tomcat 4 (happy 10 years!)

So for the first time (why? read Matthias here), we have finally a PORTABLE Bayeux protocol implementation! See the official announcement here (and how to try it).

For any questions, go to our main site and use our Nabble forum (no subscription needed) or follow us on Twitter and tweet your questions there!

technorati: atmosphere framework bayeux protocol comet

Atmosphere 0.2 GA now available

Finally, Atmosphere 0.2 released with support for annotations for REST application, improved support for Tomcat/Jetty/GlassFish, native support for JBossWeb 2.1.x, and EJB/External components broadcast lookup available.

Official announcement here

technorati: atmosphere framework jersey comet

Getting started with the Atmosphere Framework part III: Dead Simple async REST application

In that part, I describe a simple asynchronous REST application using behaviors.js, prototype.js and the Atmosphere Framework. As usual, you can deploy the app anywhere! If you interested to look for a complex Atmosphere application, take a look at the Twitter revisited one.

To understand the basic of Atmosphere, I recommend you take a quick look at part I and II. This time I will explains a simple application, which uses long polling for suspending connection. First, let's see what the war file structure looks like:

./index.html
./WEB-INF
./WEB-INF/context.xml
./WEB-INF/classes
./WEB-INF/classes/org
./WEB-INF/classes/org/atmosphere
./WEB-INF/classes/org/atmosphere/samples
./WEB-INF/classes/org/atmosphere/samples/rest
./WEB-INF/classes/org/atmosphere/samples/rest/counter
./WEB-INF/classes/org/atmosphere/samples/rest/counter/RestLongPolling.class
./WEB-INF/lib
./WEB-INF/lib/jersey-core-1.1.1-ea-SNAPSHOT.jar
./WEB-INF/lib/atmosphere-core-0.2.jar
./WEB-INF/lib/asm-3.1.jar
./WEB-INF/lib/atmosphere-portable-runtime-0.2.jar
./WEB-INF/lib/jersey-server-1.1.1-ea-SNAPSHOT.jar
./WEB-INF/lib/jsr311-api-1.1.jar
./WEB-INF/web.xml
./javascripts
./javascripts/prototype.js
./javascripts/counter.js
./javascripts/behaviour.js
./META-INF
./META-INF/context.xml
./META-INF/atmosphere.xml
./stylesheets
./stylesheets/styles-site.css

The two important files are the RestLongPolling, which contains the server side code, and the counter.js, which contains the client side code. The client simply looks like:

  1 var counter = {
  2     'poll' : function() {
  3         new Ajax.Request('dispatch/counter', {
  4             method : 'GET',
  5             onSuccess : counter.update
  6         });
  7     },
  8     'increment' : function() {
  9         var count = $('count').innerHTML * 1;
 10         new Ajax.Request('dispatch/counter/' + count, {
 11             method : 'POST'
 12         });
 13     },
 14     'update' : function() {
 15         var count = $('count').innerHTML * 1;
 16         $('count').innerHTML = count + 1;
 17         counter.poll();
 18     }
 19 }
 20 
 21 var rules = {
 22     '#increment': function(element) {
 23         element.onclick = function() {
 24             counter.increment();
 25         };
 26     }
 27 };
 28 
 29 Behaviour.register(rules);
 30 Behaviour.addLoadEvent(counter.poll);

On the screen, it looks like:

As soon as you click, the counter send a request, appending the count value to the URL. Every browser connected will be updated as soon a click event happens. The idea here is to really show something simple. Now, on the server side, we only have (I'm not kidding!):

  1 package org.atmosphere.samples.rest.counter;
  2 
  3 import com.sun.jersey.spi.resource.Singleton;
  4 import java.util.concurrent.atomic.AtomicInteger;
  5 import javax.ws.rs.GET;
  6 import javax.ws.rs.POST;
  7 import javax.ws.rs.Path;
  8 import javax.ws.rs.PathParam;
  9 import org.atmosphere.core.annotation.ResumeOnBroadcast;
 10 import org.atmosphere.core.annotation.Suspend;
 11 
 12 @Path("{counter}")
 13 @Singleton
 14 public class RestLongPolling{
 15     private final AtomicInteger counter = new AtomicInteger();
 16     
 17     @GET
 18     @Suspend
 19     public String suspend(){
 20         return "<!-- Atmosphere is your future-->";
 21     }   
 22     
 23     @POST
 24     @Path("{counter}")
 25     @ResumeOnBroadcast
 26     public String increment(@PathParam("counter") String count){
 27         counter.incrementAndGet();
 28         return counter.toString();
 29     }   
 30 }

So, when the Browser load the page, the counter.poll will invoke, on the server side the suspend() method. Since that method is annotated with the @Suspend annotation, the connection will be suspended after the method execution, waiting for event. You can see the Browser icon spinning in that demo as the GET has not yet returned. As soon as a click happens (line 8), the POST will invoke the increment(..) (line 26) method, and since the method is annotated with the @ResumeOnBroadcast, then the returned value will be broadcasted to all suspended connections, then written on the wire, and then the connection will be resumed. On the Browser side, the spinning will stop for a few milliseconds, as the Browser will re-issue a GET, which will again be suspended. Note that for that simple demo, I'm not updating the client side using the returned value of the increment(..) method to keep it extremely simple.

Now technically this application use the Atmosphere module called core, which build on top of the Comet Portable Runtime (CPR), hence allowing the application to be deployed anywhere. The CPR always auto detect the container is running on top of, like:

First with Glassfish v3:

10-Jun-2009 8:02:05 PM org.atmosphere.cpr.AtmosphereServlet loadAtmosphereDotXml
INFO: Sucessfully loaded org.atmosphere.handler.ReflectorServletProcessor@e1ca74 mapped to context-path /dispatch
10-Jun-2009 8:02:05 PM org.atmosphere.cpr.BroadcasterConfig 
INFO: DefaultBroadcaster configured using a Thread Pool of size: 2
10-Jun-2009 8:02:05 PM org.atmosphere.cpr.AtmosphereServlet autoDetectContainer
INFO: Atmosphere Framework running under container javax.servlet version 3.0

...and then Tomcat 6

INFO: DefaultBroadcaster configured using a Thread Pool of size: 2
10-Jun-2009 8:03:46 PM org.atmosphere.cpr.AtmosphereServlet autoDetectContainer
INFO: Forcing the use of the container's native Comet API implementation instead of Servlet 3.0
10-Jun-2009 8:03:46 PM org.atmosphere.cpr.AtmosphereServlet autoDetectContainer
INFO: Atmosphere Framework running under container Tomcat version 6.0.x

The two log above are showing that if the framework detect Servlet 3.0 Async Support implementation, it will use it. If not, then it will use the native Comet implementation.

Finally, two descriptors are needed to make the application works. The first one, the atmosphere.xml, just tells Atmosphere to use Jersey's Servlet to process request. Under the hood, all annotation processing and REST support comes for free from Jersey:

<atmosphere-handlers>
    <atmosphere-handler context-root="/dispatch" class-name="org.atmosphere.handler.ReflectorServletProcessor">
        <property name="servletClass" value="com.sun.jersey.spi.container.servlet.ServletContainer"/>
    </atmosphere-handler>
</atmosphere-handlers>

Next, the web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:j2ee="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    version="3.0"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee    http://java.sun.com/xml/ns/j2ee/web-app_3_0.xsd">
    <description>Atmosphere DeadSimple</description>
    <display-name>Atmosphere DeadSimple</display-name>
    <servlet>
        <description>AtmosphereServlet</description>
        <servlet-name>AtmosphereServlet</servlet-name>
        <servlet-class>org.atmosphere.cpr.AtmosphereServlet</servlet-class>
        <async-supported>true</async-supported>
        <init-param>
            <param-name>com.sun.jersey.config.property.packages</param-name>
            <param-value>org.atmosphere.samples.rest.counter</param-value>
        </init-param>
        <init-param>
            <param-name>com.sun.jersey.spi.container.ResourceFilters</param-name>
            <param-value>org.atmosphere.core.AtmosphereFilter</param-value>
        </init-param>
        <load-on-startup>0</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>AtmosphereServlet</servlet-name>
        <url-pattern>/dispatch/*</url-pattern>
    </servlet-mapping>
</web-app>

The only important line above is the init-param that tells Jersey were to lookup our resources, e.g. under org.atmosphere.samples.rest.counter. That's it. You can download the sample from here (and many more here).

For any questions, go to our main site and use our Nabble forum (no subscription needed) or follow us on Twitter and tweet your questions there!

technorati: atmosphere framework jersey comet

High Five from JavaOne

High Five from JavaOne, or 5 chances to listen to an ugly Quebecois accent.

This year I'm invading JavaOne again, and 5 times...4 times on Tuesday (nice scheduling tool...NOTD!). Which one I would pick? Well the new Atmosphere baby is certainly the one I like the most! This is the last JavaOne as we know it, so don't miss any party :-) See you there :-)

Grizzly 2.0.0-M2 released.

Small entry for those who aren't following us on twitter.com/project_grizzly. Project Grizzly 2.0.0-M2 is now officially available.

The official announcement was posted here or here. Thanks to all the feedback we have got since 2.0.0-M1 release, and don't stop!

technorati: grizzly nio framework embedded

Getting started with the Atmosphere Framework part II: Writing a REST application with Comet support

This time I will demonstrate how easy and dead simple is to write a REST application using Atmosphere annotations…with the help of Jersey!

In part I I’ve described how easy it is to write an asynchronous/comet based application using an AtmosphereHandler. I strongly recommend you first read part I to understand the steps needed to generate the proper layout for your application. I also assume you already know how to write REST application using Jersey. Why? Let me introduce a new module available with the Atmosphere Framework named atmosphere-core. As a reminder, in part I have introduced atmosphere-cpr (Comet Portable Runtime), which allow a developer to write an AtmosphereHandler and deploy it in any Servlet container. Under the hood, the CPR always make sure its use the native comet support available, e.g if deployed on WebLogic, use the AsyncServlet, if deployed in Grizzy/GlassFish, use the Grizzly Comet Framework etc. Yes, you write once and deploy everywhere your Comet application.

The atmosphere-core module builds on top of the CPR and Jersey! The aim of Atmosphere is to simplify the development of Comet application, and since every time I’ve used Jersey, I always found it is really easy to write powerful application…then I've decided to build on top of Jersey! So here we come: announcing atmosphere-core v.0.2-M1, powered by atmosphere-cpr and Jersey (including all functionality supported by Jersey!).

Like it part I, let’s first define our META-INF/atmosphere.xml:

<atmosphere-handlers>
    <atmosphere-handler context-root="/resources" class-name="org.atmosphere.handler.ReflectorServletProcessor">
        <property name="servletClass" value="com.sun.jersey.spi.container.servlet.ServletContainer"/>
    </atmosphere-handler>
</atmosphere-handlers>

If we compare with part I, this time the class-name we are using is a special AtmosphereHandler called ReflectorServletProcessor (RSP). The RSP listen to AtmosphereEvent like a normal AtmosphereHandler, but delegate the processing on the event to a servlet.service() method (a normal Servlet invocation), with a special addition which consist of storing the AtmosphereEvent as an HttpServletRequest attribute. The idea here is to support existing framework (like Jersey, Strut, JSF, etc.) without the need to modify those to support Atmosphere. Most of those frameworks support extension point, and all of them just need a reference to the AtmosphereEvent in order to suspend, resume and broadcast. Why is it called a Reflector? Mostly because every message broadcasted will be sent back to the client without any filtering or transformation. Say differently all suspended response will write as it is the message they receive (See AtmosphereHandler.onMessage for more info). Anyway as a developer you don’t need to know that…but if you are a framework developer, this is how you can use the Atmosphere Framework easily. In the current case, the RSP is configured using the Jersey’s main Servlet, called ServletContainer. As soon as you deploy your application, the Atmosphere framework will handle the lifecycle of the Jersey Servlet.

Next step is to write the web.xml:

        <servlet>
            <description>AtmosphereServlet</description>
            <servlet-name>AtmosphereServlet</servlet-name>
            <servlet-class>org.atmosphere.cpr.AtmosphereServlet</servlet-class>
            <!-- Uncomment if you want to use Servlet 3.0 Async Support
            <async-supported>true</async-supported>
            -->
            <init-param>
                <param-name>com.sun.jersey.config.property.packages</param-name>
                <param-value>org.atmosphere.samples.chat.resources</param-value>
            </init-param>
            <init-param>
                <param-name>com.sun.jersey.spi.container.ResourceFilters</param-name>
                <param-value>org.atmosphere.core.AtmosphereFilter</param-value>
            </init-param>
            <load-on-startup>0</load-on-startup>
        </servlet>
        <servlet-mapping>
            <servlet-name>AtmosphereServlet</servlet-name>
            <url-pattern>/resources/*</url-pattern>
        </servlet-mapping>

In short, we define our usual AtmosphereServlet and maps all requests to /resources to it. There is two Jersey related properties defined. The only one you need to care is com.sun.jersey.config.property.packages. The property is required by Jersey to locate where to look for your application. Eventually Atmosphere will auto detect those, but for now you need to add it. In our case, it the fully qualified name of the package of our application. The second property is the Jersey extension point. No need to talk about it this time.

We are now ready to re-write the chat demo described in part I, re-using the same javascript code on the client side but this time without using any AtmosphereHandler, AtmosphereEvent, or Broadcaster, but instead using annotation (yeah!). Let’s start with the survival tool of Atmosphere annotation, which are @Suspend, @Resume and @Broadcast. You can write very powerful application by just using those I will talk about more annotations in part III). What the annotations are for:

• @Suspend: write the returned value of the annotated method, then suspend the response
• @Resume: resume the response by committing it
• @Broadcast: broadcast to all suspended connection the returned value of the annotated method

So without going into the details of REST and Jersey (see this tutorial), writing a chat application just consist of:

 
    @Suspend // the returned String will be written and then response suspended
    @GET
    @Produces("text/html")
    public String cometGet() {
        return "<!-- Comet is a programming technique that enables web " +
                    "servers to send data to the client without having any need " +
                    "for the client to request it. -->\n";
    }

    @Broadcast // The returned String will be broadcasted to all suspended response.
    @Consumes("application/x-www-form-urlencoded")
    @POST
    @Produces("text/html")
    public String cometPost(
       @FormParam("action") String action,
       @FormParam("name") String name,
        MultivaluedMap form) { 

        if ("login".equals(action)) {
            return BEGIN_SCRIPT_TAG + toJsonp("System Message", name + " has joined.") + END_SCRIPT_TAG;
        } else if ("post".equals(action)) {
            return BEGIN_SCRIPT_TAG + toJsonp(name, form.getFirst("message")) + END_SCRIPT_TAG;
        } else {
            throw new WebApplicationException(422);
        }
    }

Simple, is it? The way it works is the cometGet will be invoked, its returned value will be written back to the client and the response suspended. When the cometPost gets invoked, it’s returned value will be broadcasted, e.g. all suspended responses will be invoked and the value written as it is to the client since we are using the ReflectorServletProcessor. That’s it! With the use of two simple annotations, we were able to write our first atmosphere-core REST based application. OK, it's REST twisted, but still :-).

You can download the entire application here, or browse the source code. If you are already using Atmosphere, you must upgrade to Atmosphere 0.2-M1 to take advantages of those new functionality.

As usual, THANKS to the great feedback I’ve got so far. Early adopter, you make a big difference! For any questions, go to our main site and use our Nabble forum (no subscription needed) or follow us on Twitter and tweet your questions there! And if you are going to JavaOne, don’t miss the Atmosphere BOF on Tuesday @ 8h30pm with Jersey lead and Java Champion’s Paul Sandoz, which is a great speaker without a Quebecois accent

technorati: atmosphere comet

Atmosphere 0.1 GA available with Twitter, Flickr and Chat sample

After couple of weeks collecting feedback from the newly created community (THANKS!), Atmosphere 0.1 GA is now available with support for Glassfish 1/2/3, Weblogic 9.x and up, Tomcat 4/5/6, Jetty 4/5/6/7, Grizzly 1.9.x, Winstone, etc.

All of the above containers are supported out-of-the-box, e.g. you download our web.xml template, set your servlet-mapping, and you ready to write a portable Comet application. Based on the container you are running on, Atmosphere will auto-detect their native Comet API and uses it, or fake it if not found (like Tomcat 4). The only one "container" that doesn't work is...Servlet 3.0 Async proposal! Why? Because Servlet 3.0 Async is not enabled by default (strange decision ;-)) so you must either annotate your Servlet to tell the container you want to use async features, or you add a special element in web.xml. But since it requires the Servlet 3.0 DTD, Atmosphere cannot support 3.0 Async as an application using a web.xml targeted for 3.0 will not deploy in Servlet 2.5 Container (the majority of them!). Yes, that's bad (to not say that suck..I did try all kind of hack without success!)! So if you want to use Atmosphere with Servlet 3.0, your application will not be portable..unless you switch your web.xml...NOT! Hopefully I can make the Servlet team change their decision as this is really really bad for any framework that want to support 3.0 and existing native Comet implementation.

Atmosphere 0.1 natively supports:

• GlassFish (Grizzly Comet)
• Weblogic Async Servlet (9.x and up)
• Tomcat AIO (Tomcat 6, JBoss Web)
• Jetty Continuation
• And emulate Comet on any others Servlet Container supporting the Spec version 2.3 and up

How to get started? Read this simple intro (or just drop Atmosphere CPR under WEB-INF/lib) or download one of our samples

• Twitter: A Twitter like application
• Flickr Magnet: Move Flickr Words all over the place!
• Chat : The Hello word of Comet

What's next? Before 0.2 release my plan is to write a complete tutorial which demonstrate all the Atmosphere powerful features. Even now, it is crystal clear than writing a Comet application is much more easy and fast than using any native implementation, including the upcoming Servlet 3.0. So start today using it!

As usual, feedback appreciated by either sending your questions to users@atmosphere.dev.java.net or by tweeting us!

technorati: atmosphere comet

Grizzly 2.0.0-M1 released! With extra: History of Grizzly

Today we are releasing our first Grizzly 2.0 release, which we are working on since almost 2 years. Get ready for the revolution! But how this Grizzly things started?

It has been years since I've jumped into the blogosphere and started talking about Grizzly. Officially, Grizzly started in 2004 when Vivek Nagar and I talked about NIO. At that time I wanted to propose a new Tomcat connection based on NIO but got some resistance with the other developers. So we decided to keep it for us, specially after we did some benchmarks against the Netscape's WebServer Sun have :-). Developing Grizzly 0.x was a challenge as it was "sandboxed" by our application server internal API (and gigantic "resistance" from the think thanks ;-)). I wasn't allow to change any API there (quite a challenge)...Grizzly 1.0 was born in a sandbox, and yes some of its design was horrible, but the SJS AS team was happy as no API were changed and Grizzly got finally accepted in SJSAS 8.1 PE (not EE :-)) Then we open sourced what has becomes GlassFish and make a lot of noise about Grizzly/GlassFish. Starting from zero, we then worked hard to build a community around Grizzly inside GlassFish. We got a surprisingly nice numbers of early adopter event if the API were not perfect. Amongst them was Phobos, AsyncWeb, Jetty, Sailfin Convergence Load Balancer (zzzzzz Sailfin uses Grizzly 1.0 and 1.8.6 under the hood, but they don't talk about it;-)), GlassFish v3, and the popular Grizzly JRuby (which is still the foundation of GlassFish v3's JRuby support!).

Over 2006, we worked the next version, called Peregrine, with peoples from MQ, IIOP, Performance, SOA, etc. During that time, we also saw the Grizzly community growing and we've decided to release an intermediate version 1.5, which goal was to not break the compatibility with 1.0. That was an extremely tough decision for me as it left aside a lot of great designs/code Charlie did for Peregrine. But now I think we took the right decision, looking at the adoption and more important, the community around Grizzly.

We have then started working on Grizzly 2.0 based on what we have learned from 1.x, 1.5.x, Peregrine, the current community feedback and of course new ideas, without sandboxing ourself (so breaking compatibility with the NIO framework 1.9.x). We also switched the lead so API gets better designed without noise from the pass :-)...we also merged Ken's and John works, let Alexey innovates and now get ready!. With this healthy community we are now ready to make the big step: 2.0.0-M1 is now available for download

Read Alexey's blog about what this release include, download it, browse Javadoc or gives feedback on users@grizzly.dev.java.net. Now what will happens with 1.9.15 and up? We will maintain innovations for the 1.9.15 event after 2.0.0 GA as we don't want to force the community to upgrade. More important, we stay untouched the popular APIs like GrizzlyWebServer (I,II,II,IV, V, VI). So we have years before us :-) Also major users of 1.9.x (to name one: GlassFish v3!) will soon be released so we have no plan to stop innovating/fixing bugs with 1.9.x...we still fix issues for 1.0.x users, so no worries! Want to follow more about the monster community? Follow us on Twitter!

technorati: grizzly web server embedded

1.9.11 released! What's cool with Grizzly 1.9.11?

Grizzly 1.9.11 is freshly released. What's cool? Get ready: Servlet Deployer, HttpService OSGi spec support, XML config a la "Spring", Performance improvement...and a new LOGO. Meet the new monster!

Here we go with a subset of what WE accomplished since our last release. The difference? Sun representative are now in minority, and we are getting patch after patch after patch for with new feature!. Here is a summary of what's new:

• http-servlet-deployer: A new Servlet Deployer for the http-servlet module. Fully deploy your war on the monster! You can run that module from the command line (or embed) and deploy war file on the fly. Support 2.x/3.0 web.xml
• config: A new configuration module that allow the creation of Grizzly's application from an XML file. This will be extensively used by GlassFish but can also be used with Grizzly.
• mod_jk support: You can now cluster GrizzlyAdapter and front them using Apache 2
• HttpService OSGI support: Yes we fully support that spec now!!
• Innovate on Grizzly, deploy on GlassFish v3: Deploy your GrizzlyAdapter on GlassFish v3 and get all the cool functionality for free!
• Grizzly SSLConfig: make SSL configuration fun!
• And some performance improvement, some bug fixes (thanks for all the patches), etc...complete log here

What's next: WebSocket support, http client, leader follower thread pool support, WarAdapter, etc...and Grizzly 2.0 M1 most probably next week!

For any questions, post them to users@grizzly.dev.java.net or tweet us here.

technorati: grizzly web server

Extending the Grizzly HTTP Runtime VII: Cluster/load balance GrizzlyAdapter using Apache

With the release of Grizzly 1.9.11, it is now possible to cluster/load balance your GrizzlyAdapter using Apache!

As I described in the previous entry on the topic(I,II,II,IV, V, VI), it is quite simple to embed Grizzly using its' extension point: GrizzlyAdapter:

        GrizzlyWebServer ws = new GrizzlyWebServer("/var/www");
        try{
            ws.addGrizzlyAdapter(new GrizzlyAdapter(){  
                
                public void service(GrizzlyRequest request, GrizzlyResponse response){
                    try {
                        response.getWriter().println("Grizzly is so cool!!!");
                    } catch (IOException ex) {                        
                    }
                }
            });
            ws.start();
        } catch (IOException ex){
            // Something when wrong.
        }

Now let's assume you want to add clustering/load balancing support to your GrizzlyAdapter. To add such support, let's use Apache 2 and mod_jk. To install mod_jk and Apache, just install mod_jk module (see here for an example):

LoadModule jk_module /usr/apache2/httpd/modules/mod_jk.so
JkWorkersFile /etc/apache2/conf/worker.properties
# Where to put jk logs
JkLogFile /var/log/apache2/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel debug
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"
# Send all grizzly/ requests to Grizzly
JkMount /grizzly/* worker1


The add in your /etc/apache2/worker.properties


# Define 1 real worker using ajp13
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost.localdomain
worker.worker1.port=8009
worker.worker1.lbfactor=50
worker.worker1.cachesize=10
worker.worker1.cache_timeout=600
worker.worker1.socket_keepalive=1
worker.worker1.socket_timeout=300

With the above, we are telling Apache to forward (via mod_jk) all requests starting with /grizzly to .... GrizzlyWebServer! How? Let's take the previous example and add support for mod_jk:

        GrizzlyWebServer ws = new GrizzlyWebServer("/var/www");
        try{
            ws.addGrizzlyAdapter(new GrizzlyAdapter(){  
                
                public void service(GrizzlyRequest request, GrizzlyResponse response){
                    try {
                        response.getWriter().println("Grizzly is so cool!!!");
                    } catch (IOException ex) {                        
                    }
                }
            });
            ws.enableProtocol(PROTOCOL.AJP);
            ws.start();
        } catch (IOException ex){
            // Something when wrong.
        }

Just compile, java -jar ...That's it! Now any blog talking about mod_jk clustering/load balancing configuration can be used with your GrizzlyAdapter. As an example, take a look at this one

For any questions, post them to users@grizzly.dev.java.net or tweet us here.

technorati: grizzly web server embedded

July 2009

Search this blog:

Categories

Archives

June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
June 2005

Recent Entries

Finally a portable implementation! The Bayeux protocol now supported by the Atmosphere Framework

Atmosphere 0.2 GA now available

Getting started with the Atmosphere Framework part III: Dead Simple async REST application

This work is licensed under a Creative Commons License.