Home > grails, osgi > Grails on OSGi (1): Thoughts

Grails on OSGi (1): Thoughts

November 16th, 2009

What is OSGi

The OSGi Alliance (formerly known as the Open Services Gateway initiative) is a consortium of companies in the Java world, which develop the OSGi Service Platform, a framework for component-oriented software. Originally developed for embeded devices, OSGi frameworks can now also be found in enterprise, mobile, home, telematics and consumer products.

Applications in an OSGi environment are split into individual modules called bundles, which are usually provided as jar files. Each bundle provides a manifest file containing meta data, which describe its name, version, dependencies and offerings, i.e. code and services. An OSGi container can host multiple applications at once, each application can be started or stopped any time.

The OSGi specifications describe both the core framework and a set of standard services for common functionality such as logging, web access, declarative services, etc. A more detailed description can be found here.

There are multiple OSGi implementations available. Well-known open source implementations include Equinox, which is the base for the Eclipse IDE and eco system, Apache Felix and Knopflerfish.


Running a Grails application in an OSGi environment would bring some benefits:

  • Support for modularization
  • Handling and versioning of components and dependencies (*)
  • Separation of applications
  • Dependencies and used libraries can be transferred independently to the application server, which makes for smaller application bundles and therefore faster transmission
  • Easy in-place update and reloading of individual components during runtime
  • Service-oriented architecture

(*) Alltough starting with version 1.2 Grails provides good support for versioning and dependency resolution with the integration of Ivy)

Progress so far

JIRA issue GRAILS-2221 for OSGi support for Grails exists for quite some time. Originally OSGi support was requested with an eye towards a plugin system. Grails now has its own plugin system, but OSGi support is on the roadmap for Grails 2.0, whenever that will be released 😉

Update: Grails 1.2 will contain a valid OSGi bundle manifest, so the Grails jars may already be pulled out of a Grails application bundle and installed sepearately.

Possible implementation levels

There are several possibilities running a Grails application in an OSGi environment:

  • Monolithic application (Compatibility mode)
  • Modularized application
  • Fully componentized application

Monolithic application (Compatibility mode)

This can be seen as a first step of an OSGi-fied Grails application and should be already possible today with some manual steps.

The Grails application is packaged as a WAR file with the manifest file containing necessary OSGi headers, like Bundle-SymbolicName, Bundle-Version, Bundle-ClassPath, and Import-Package.

An OSGi framework providing a web service and corresponding web extender like Spring-DM or Pax Web can now run this application.


  • Already possible today
  • No classloading issues


  • No modularization
  • Big, monolithic bundle, slow upload to an application server

Modularized application

The next step will be splitting a Grails application into individual bundles. Ideally each of Grails’ and the application’s dependencies like Hibernate, Sitemesh, etc. would come as its own (set of) bundle(s).

Spring and Groovy already contain OSGi meta data and can be run unmodified in an OSGi environment, OSGi-fied bundles of some other dependencies can be found in the bundle repositories provided by SpringSource, Apache Felix, or Knopflerfish. Eclipse also hosts some third-party libraries, e.g. many commonly-used Apache jars, which were converted to OSGi bundles, in the Orbit project.

The Grails application itself would be another bundle. As it contains no dependencies, it would be quite small and can therefore easily be transferred to an application server.


  • Shared dependencies for all Grails applications
  • Small bundle for faster upload to an application server


  • Issues with Grails’ singletons, when running more than one Grails application in a single VM (*)
  • Classloading issues

(*) This is also the case when running more than one Grails application in a servlet container with shared jars, e.g. using grails war --nojars.

Fully componentized application

Many posts on the Grails mailing list ask for ways to modularize big web applications. The most common answer and approach is to split the application into multiple Grails plugins.

In an OSGi environment, the Grails application could be split into multiple bundles, each of which can be individually updated or reloaded. Each Grails plugin would compose a bundle of its own, which could be used and shared by multiple Grails applications.

A starting point for implementing this approach could be the newly created Spring Slices project.


  • Full modularization
  • Small bundles for fast uploads to an application server


  • Issues with Grails’ singletons, when running more than one Grails application in a single VM
  • Classloading issues

OSGi-fied Development mode

The Grails development mode (aka grails run-app) could also profit from OSGi support. With the OSGi framework constantly running, changes could be integrated by simply updating or reloading individual bundles. Even major changes would only mean reloading some bundles. This would reduce startup times, as the VM is always running and does not need to be stopped and restarted.

For extreme cases, each controller/domain class/Grails artefact could even be temporarily packaged in its own bundle.


Real OSGi support for Grails is still some time in the future. There is a lot to do and some issues regarding classloading and singletons to resolve. This series of blog posts will look at OSGi support from different angles and try to find solutions to emerging problems. Stay tuned…

Categories: grails, osgi Tags:
  1. btilford
    November 16th, 2009 at 05:25 | #1

    I think grails has 2 major issues to overcome when trying to modularize.
    1) The convention used by the project is pretty brittle (using directories where annotations should have been used)
    2) GSP / JSP can not be modularized in an acceptable way. (looking at Slices I suppose it could be done but it’s still not really an ideal way to do it)

Comments are closed.
Fork me on GitHub