Archive for July, 2010

Grails on OSGi: Released Grails OSGi plugin 0.2.1

July 27th, 2010 6 comments

I just released a small update for the OSGi plugin, which fixes dependency resolution for Spring DM.

Thanks to lemnitram and Klaus Baumecker for reporting it.

Spring DM 2.0 is currently only available as snapshot release (2.0.0.M1). The jars used to be available from other repositories (e.g. SpringSource Enterprise Bundle Repository (EBR)), but they have vanished, so I needed to add the Spring Milestone Repository.

For installation and usage of the plugin see me previous blog post and the docs.

Spring DM has been donated to the Eclipse Foundation by SpringSource, where it will be part of the Gemini Blueprint and Gemini Web projects. This means, that Spring DM 2.0 will never be released, so the OSGi Plugin needs to be ported to use Gemini Blueprint and Gemini Web instead. This will happen in the 0.3 release.

Categories: general Tags:

Grails on OSGi: Released Grails OSGi plugin 0.2

July 12th, 2010 3 comments

I just released version 0.2 of my OSGi plugin for Grails. The OSGi plugin is released under the Apache License 2.0.

The Grails OSGi plugin adds support to package and run a Grails application as an OSGi bundle. The bundle(s) may be run in an ad hoc assembled OSGi container or deployed to an external OSGi app server such as SpringSource DM Server, Eclipse Virgo, or Apache Karaf.

See my blog series for earlier thoughts and information for running a Grails application in an OSGi environment as well as concepts of and basic information on OSGi.

This post and the following installments of the series will show how to use the plugin and present some examples.


Simply call grails install-plugin osgi to install the OSGi plugin.


Creating an OSGi bundle from the Grails application

grails bundle
grails prod bundle

Running the bundle

grails run-bundle
grails prod run-bundle

The application can be accessed at http://localhost:8080/myapp-0.1/.

Note: at first start the OSGi runtime is assembled, which may take some time, while Ivy is downloading the Internet…

Note: if the bundle exists, it won’t be re-created automatically after changes. So for now use parameter -forceBundle after changing something in the Grails app: grails run-bundle -forceBundle.

Accessing the bundle context

The bundle context is the primary interface to the OSGi framework. It can be used to find and register services and interact the environment.

The bundle context is available from Grails’ parent ApplicationContext as bean bundleContext. It can be injected into all Spring-managed beans, i.e. all Grails artifacts, like Controllers, Services, etc.

In order to get a reference to the BundleContext, an artifact needs to define a reference with the name bundleContext.

Example: controller accessing bundle context

class OsgiTestController {
    def bundleContext
    def index = {
        def bundles = []
        if (bundleContext) {
            bundles = bundleContext.bundles
        else {
            flash.message = "bundleContext NOT available"
        [ bundles: bundles ]

Changes since version 0.1

  • using Spring DM instead of Pax Web as Web extender
  • updated Apache Felix WebConsole
  • replaced (most) dependencies from bundle by OSGi bundles from the SpringSource Enterprise Bundle Repository (EBR)
  • provide access to OSGi BundleContext to artifacts (controllers, services, …) via Spring injection as bean bundleContext

How it works

In order to be a valid OSGi bundle, the application is war’ed and provided with the necessary bundle manifest headers (see scripts/_Events.groovy for details).
The bundle can be created using grails bundle.

The OSGi runtime is assembled in the target/osgi directory and uses the Eclipse Equinox OSGi framework, Spring DM.

In the current version, most libraries from WEB-INF/lib are replaced by equivalent OSGi bundles from the SpringSource Enterprise Bundle Repository (EBR). Only Hibernate and Grails libs retain in the bundle.

Grails jars already are OSGi bundles, but they cannot currently be installed cleanly in a OSGi container, as they contain circular dependencies and some other dependencies can not be satisfied (e.g. the Radeox library used by the Grails Wiki is no longer maintained, but it shouldn’t be referenced from the Grails runtime anyway…).

There are bundles for Hibernate but due to a bug (possibly in Equinox), Hibernate Cache can not be resolved by the Spring ORM module (see “SPR-7003”: for a description of this problem).

The parent ApplicationContext has been replaced in web.xml by an OSGi-aware variant: OsgiBundleXmlWebApplicationContext. It knows how to export and import OSGi services as/from Spring beans through Spring XML files. These features are currently hidden, but they will be exposed in the next version of the OSGi plugin and made easier through the BeanBuilder DSL and the OSGi namespace.


  • make bundle generation configurable (e.g. include/exclude dependencies, …)
  • make OSGi runtime created by grails run-bundle and grails assemble-osgi-runtime configurable
  • support auto-reloading of changed artifacts
  • create sub class of GrailsApplicationContext, which implements ConfigurableOsgiBundleApplicationContext
  • export main Grails beans and application context as OSGi service
  • export services as OSGi service (via static expose = 'osgi')
  • implement deployment to SpringSource DM Server or its successor Eclipse Virgo
  • implement deployment to Apache Karaf
  • Spring DM has been donated to Eclipse, so it should be replaced by its successor Eclipse Gemini

Getting around the OSGi runtime

Web Console

The “Felix Web Management Console”: provides excellent insight into the inner workings. It can be accessed at http://localhost:8081/system/console/ with user “admin” and password “admin” (Note: the web console runs on a different port!).

Shell Console

The command grails run-bundle drops the user in the Equinox Shell (press RETURN if you don’t see the osgi> prompt). Running grails run-bundle -remoteConsole [port] opens a console with telnet access on the specified port or on port 8023, if omitted. Only a single user can use the console at any time.

Categories: general Tags:

Released Grails Spy plugin 0.2

July 6th, 2010 Comments off

I just released version 0.2 of my Grails Spy plugin.


The Grails Spy plugin provides some views to inspect Grails internals such as the Spring application context(s), artefacts, etc.

As most of the beans of the Grails WebApplicationContext are constructed at runtime with the help of a BeanBuilder, there is no Spring xml file with bean definitions.

In order to browse the dynamic bean definitions, Grails Spy can be used to watch into an application’s guts.


grails install-plugin spy


Simply install the plugin, enable the Spy controller for the dev environment and run grails run-app. Then browse to http://localhost:8080/yourapp/spy and enjoy.


  • For security reasons the Spy controller must now be enabled in Config.groovy:
    grails.plugins.spy.enabled = true

    The plugin can be enabled or disabled individually for each environment. Example:

    environments {
        production {
            grails.serverURL = ""
        development {
            grails.serverURL = "http://localhost:8080/${appName}"
    	grails.plugins.spy.enabled = true
        test {
            grails.serverURL = "http://localhost:8080/${appName}"
  • 'inspect' is now the default action for the spy controller, so it can be called as http://localhost:8080/yourapp/spy instead of http://localhost:8080/yourapp/spy/inspect


The Spy plugin is released under the Apache License 2.0.

Source code and Issues

The source code is hosted at GitHub, issues can be reported here.


Eye-candy you say? See below:

GrailsSpy: GrailsApplication

GrailsSpy: ApplicationContext view

GrailsSpy: bean view

Categories: grails, plugin, spy Tags:
Fork me on GitHub