Grizzly OSGi Http Service Guide

This post is an introduction to Grizzly OSGi Http Service.

Code for this post is available as Gitorial: http://github.com/neotyk/httpservice-gitorial/commits/master.

You'll find here:

• how to use Grizzly OSGi Http Service
• how to configure Grizzly OSGi Http Service
• how to register servlet and resource
• how to perform authentication on registered servlet or resource
• what is currently implemented from spec and what is missing

Introduction

Grizzly

The Grizzly framework has been designed to help developers to take advantage of the Java™ NIO API. Grizzly goals is to help developers to build scalable and robust servers using NIO and we are also offering embeddable components supporting HTTP, Bayeux Protocol, Servlet (Partially) and Comet.

OSGi

OSGi is the powerful dynamic framework that underlies the Eclipse IDE and platform, but its use is not restricted to Eclipse. In fact it is used everywhere from mobile phone and vehicle entertainment systems to enterprise application servers. It is, essentially, the module system for Java.

It's lightweight and let's you escape JAR hell.

OSGi Http Service

The Http Service allows other bundles in the OSGi environment to dynamically register resources and servlets into the URI namespace of Http Service. A bundle may later unregister its resources or servlets.

Usage

Grizzly OSGi Http Service is available in two versions one with it's all dependencies and one by itself.
For version with dependencies you'll need to depend on:

For version without dependencies you'll need:

And examine its pom.xml to see dependencies that you'll need to satisfy.
Workspace with specified dependency on -bundle version is here.
Remember that even if you are using -bundle version you'll need to specify dependencies on org.osgi.core and org.osgi.compendium.
Next you'll need to configure bundle packaging as shown here.
Now you can configure your project to use maven-pax-plugin as specified here so you can do mvn pax:provision for easy startup of OSGi with your bundle and its dependencies provisioned.

Configuration

If you've tried mvn pax:provision from previous step you probably have seen exception that Grizzly OSGi Http Service couldn't bind to port 80.
Binding to port <1024 on most platforms requires special permissions.
Grizzly OSGi Http Service tried to bind to port 80 because it has not been configured to do otherwise, this is specified by spec as default.
To configure port that OSGi Http Service binds to you'll need to configure org.osgi.service.http.port property.
This configuration change is shown here.

Registration

In OSGi Http Service to expose something via http you have to register it.
But before you do it lets configure Declarative Services and Dependencies, this will allow much easier integration with OSGi Http Service.
Checkout this commit to see how to enable it.
Now that we have made our life easier lets get to registering Servlet and Resources.

Registering Servlet

To register a servlet you need to call HttpService.registerServlet method. Last two parameters (initparams and context) can be null for now.
alias is name in the URI namespace at which the servlet is registered,
servlet is servlet to register.
To see changes been done already, click.

Registering Resources

Registering resources is way to expose static content in OSGi Http Service.
To register resources you need to call HttpService.registerResources method. Last parameter context is optional and can be null for now.
alias is name in the URI namespace at which the resources are registered,
name is the base name of the resources that will be registered.
For working example go here.

Authentication

So far registering dynamic and static content has been described, that is nice but what if you would like to secure it?
Sure thing, you just need to provide last parameter (context) to resource/servlet registration.
If you don't provide context default context is used and this one is allowing all access.
Your authentication have to be implemented in HttpContext.handleSecurity.
This method is called by OSGi Http Service before request is handled. If your implementation returns true the request should be serviced, false if the request should not be serviced and Http Service will send the response back to the client.
And you probably saw it coming, here is a code for it.

Status

Not all specification has been implemented.
Things not implemented yet are:

• SSL support,
• Security as described in 102.8 Security

Those things will get implemented if users will be interested in it.
Rest was implemented as specification requested.


Enjoy working with Grizzly OSGi Http Service and make sure to report issues as well as success stories to Grizzly Users List.