Search |
||
Extending the Grizzly HTTP Runtime part V: Programatically configuring Servlet and GrizzlyAdapterPosted by jfarcand on January 8, 2009 at 4:12 PM PST
A lot of applications/framework (like Jersey, Hudson, DWR, etc.) out there just consist of a single Servlet which dispatch requests to its appropriate internal components. In such case, a full blown Servlet Container might not be needed....but a tiny 800k Grizzly might be! Like I've described in previous post on the topic (I,II,II,IV), it is extremely simple to build an HTTP extension/WebServer using Grizzly: In 30 lines you just wrote a simple file server. But what about Servlet? Let's take a very difficult application and try to launch it with Grizzly: Hudson. Let's programmatically configure Hudson, similar to what we did for our simple file server. First, let's create a simple wrapper. As you can see, this is quite simple. First, we create an instance of ServletAdapter (line 2), then configure the appropriate Servlet, Filter, and deployment information (line 8 to 21), taken from Hudson's web.xml. Note line 23 where we finally add the Adapter to GrizzlyWebServer: just pass the ServletAdapter and a mapping (context) used to map requests. That's it. You can download the result here and lunch Hudson on top of Grizzly by just doing: OK but this is cool as a demo, but doesn't add anything special to Hudson. Let's extends it by adding a chat functionality so we can blame each other when someone breaks the build. Let first add another Adapter that support the Bayeux protocol so we can chat using Comet So now we can package our 24 lines of code, and have a very small Hudson server with chat capability. Requests to /hudson goes to Hudson, /cometd goes to our Bayeux/Cometd chat application. Nothing fancy here as you can already do that using GlassFish. But quite simple to do it programmatically!. Another way to add Bayeux support could have been: A little more complicated, but just to demonstrate how to programmatically deploy more than one Servlet. Want to try it? download the grizzly-webserver.jar and uses your favorite IDE to build powerful HTTP based applications. Need help: ping us on users@grizzly.dev.java.net, or Tweet us on Twitter. technorati: grizzly web server embedded »
Related Topics >>
Glassfish Comments
Comments are listed in date ascending order (oldest first)
Submitted by jfarcand on Mon, 2009-01-12 10:01.
See the answer here: http://tinyurl.com/9p6kmm and the following discussion.
Submitted by braghest on Fri, 2009-01-23 12:42.
When adding filters is it also possible to set a filter mapping and the dispatcher types? I need this and it can be done with Jetty.
Submitted by jfarcand on Fri, 2009-01-23 12:51.
I've posted the response here -> http://tinyurl.com/btmo2x so the community can comments/help. Thanks!!
Submitted by braghest on Sat, 2009-01-24 14:18.
I see, thank you. However my use case is a bit more complicated ;-) I have two filters with different mappings and a context listener. It is important that the listener has servlet API semantics (singleton, methods invoked just once, ...).
Currently my code in Jetty looks with this:
Context context = new Context(null, "/", options);
context.addEventListener(new EventListener());
context.addFilter(AFilter.class, "/a*", Handler.REQUEST);
context.addFilter(BFilter.class, "/b*", Handler.REQUEST);
which is very simple. I fear that when I add two ServletAdapters to a GrizzlyWebServer or a GrizzlyAdapterChain that the context listener will receive events twice.
Submitted by jfarcand on Mon, 2009-01-26 18:57.
@bragest -> I've posted the response here: http://is.gd/hlgc . Ins hort. I agree with you we need to improve the API.
|
||
|
|
I say so because I currently use Jetty embedded and I use always the same "Jetty launcher" code and I just point it to the proper directory to be mounted and it reads the web.xml and deploys the application, etc.
This was I can re-use the same code for every tiny application I want to, without harcoding the servlets, filters etc. that I need. And at the same time, the web application can be mounted in a regular container without a change.
I understand how doing everything in code can be very useful sometimes, but in my case I'd rather do it like that..
Salute and good job!