Showing posts with label osgi. Show all posts
Showing posts with label osgi. Show all posts

Saturday, March 14, 2009

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.

Tuesday, February 3, 2009

Wednesday, December 24, 2008

Grizzly OSGi Archetype

This is take 2 of Grizzly on OSGi platform (take 1).

Previous problems running this configuration has been solved by Grizzly Devs, awesome feedback.

So if you want a Quick Start for Grizzly on OSGi jump to your console and execute following:
mvn archetype:generate -DarchetypeCatalog=http://kungfoo-m2.googlecode.com/svn/trunk/archetype-catalog.xml
This should allow you to choose grizzly-osgi-startup project and provide all necessary project details.
Next thing you do is to cd to newly created project and execute:
mvn clean install pax:provision
Now you should have Felix (default for Pax, you can choose other platform providers) running your bundle that uses Grizzly and is listening on localhost:8282.

Have fun Grizzling in OSGi.

Friday, December 19, 2008

Grizzly OSGi

As a side effect of working on Grizzly Proxy simple project showing how to use Grizzly in OSGi environment popped up.

Links:
Hope to have archetype available soon, will keep you posted.

Grizzly proxy

After Devoxx I finnaly started working on Grizzly Proxy Server.
Project page and sources tree are available.

For now proxy is not functional.
Initialy I used commons-httpclient to make connections to target server.
This turned out to be not really nice since httpclient is blocking.

My current focus is to change it to use HttpCore and especially I'm interested in NIO Extensions Module.
This will allow much better scaling, but still will relly on two difrent APIs, and I'm dont think I like having it done like that.

Once Grizzly team releases thair HTTP Client I'm going to switch to it.
So don't expect g-http-proxy to be usable right now, but keep an eye on it, and fill free to contribute.

g-http-proxy is OSGi bundle :)

Thanks for listening and stay tuned.