The OSGi (http://www.osgi.org/) framework is a powerful Java tool providing component based service and dependency management. OSGi components can be remotely installed, started, stopped, updated and uninstalled without shutting down your application. Also, OSGi provides far greater dependency management than the basic Java classpath mechanism, allowing you to specify specific versions of dependencies and keep dependencies private so that other components cannot load them. One of the most notable usages of OSGi is the Eclipse Plugin Container. A good starting point for more information is the Wikipedia page http://en.wikipedia.org/wiki/OSGi and the Further Reading section of this document.
Loading Groovy as an OSGi service
The Groovy jar files are released with correct OSGi metadata, so they can be loaded into any OSGi compliant container, such as Eclipse Equinox or Apache Felix. The metadata can be viewed by looking at the jar file's MANIFEST.MF file. For instance, your Jar manifest might contain these lines:
This declares to the OSGi container that the Jar is version 1.7.0 and provides the specified packages for import by other components.
The following examples all use the Eclipse Equinox container, which can be downloaded from the Internet or found in an Eclipse installation.
Perform the following steps to install and start the Groovy Jar in an OSGi container:
Start the OSGi container in console mode:
This should bring up an OSGi console prompt:
You can see the system status of the container at any time using the "ss" command.
Install the Groovy jar file using "install" and a file URL to your groovy-all jar:
The container will assign the bundle an identifier. Start the bundle using the "start" command:
Verify the bundle is started using "ss":
You can list all the packages the Groovy bundle provides with the "packages" command:
Writing a Groovy OSGi Service
Once the Groovy jar is loaded into the container, writing an OSGi service that uses Groovy is as simple as creating a subclass of the framework's BundleActivator class.
The Activator's start(BundleContext) method will be invoked when the container starts the service, and the stop(BundleContext) method will be invoked when the container stops the service.
The first step in deploying the new Groovy service is to create a jar file containing the Activator. The manifest for the Jar needs to specify the name of the new service, the version, the fully qualified path to the Activator, and which packages from the groovy-all jar bundle to import. The complete manifest for this example follows:
The Import-Package statement is important. It states all the dependencies from the Groovy-all jar which are allowed to be referenced. The Groovy-all Jar exports many, many more packages than just this... an Import-Package definition with just enough dependencies to get the println to work correctly is shown here. In a more meaningful Activator you'd want to import many more of the packages.
The complete Jar for this example has a layout as follows:
Test the new Hello-Groovy bundle by running the OSGi console and issuing the following commands, using "ss" to verify that the correct dependencies are loaded beforehand:
The start and stop message shows that the Groovy service was correctly started and stopped.
Including the Groovy Jar within a Bundle
The previous example shows how to resolve an Activator's Groovy dependency from the container. The Activator can only be started after the Groovy bundle is started. An alternative is to simply include the groovy-all jar within your bundle. This eliminates the need to declare Import-Packages, but does bloat the size of the jar. Any Jar file included within your bundle has private visibility and cannot be referenced by any other bundles that happen to be running in the container.
To include the groovy-all jar within your bundle, rather than loading it from the container, create your Jar with a layout as follows:
And use this template as the MANIFEST.MF:
The Jar can now be loaded and started in the container without first loading the Groovy Jar. Verify this but running the following within the console:
Publishing a Service Written in Groovy
Publishing a service written in Groovy requires one extra step that a Java service does not. This is because of the way Groovy makes extensive use of ClassLoaders and reflection. When registering a service with the BundleContext, you must be sure to temporarily set the current thread's ContextClassLoader to the target object's ClassLoader, and then set it back when you're done. It's actually quite easy, and this example walks you through this one detail.
In order to demonstrate registering a service, we need to create a sample service in Groovy. This is just a POGO interface and implementation. Consider the GroovyGreeter which simply prints a message to the console.
GroovyGreeter.groovy defines the interface:
And GroovyGreeterImpl.groovy defines the implementation:
Now the Activator can create an instance of GroovyGreeterImpl and register it with the container as a GroovyGreeter provider. In Java, you'd need one line to call BundleContext.registerService(String, Object, Dictionary), but in Java we need to change the ContextClassLoader while we do this. Here is a complete and correct Activator:
The Jar file for this bundle is similar to the first example's:
The Jar Manifest is almost the same as the first example. The change is the Export-Package statement. Since we are registering the a service org.codehaus.groovy.osgi,GroovyGreeter, we need to specify that package and version in an Export-Package statement:
Notice, also, how this bundle is importing the Groovy Jar from the container, it does not contain the Groovy Jar within itself. To verify and test this, use the OSGi console to install and start the groovy-all Jar and then install and start this Jar.
Consuming a service (the groovy-ness of which is immaterial)
Missing Constraint: Import-Package: groovy.lang; version="1.7.0.beta-1-SNAPSHOT"
Sunil Patil wrote a 3 part writeup with full code listings on JavaWorld. Part 1 details the basics os a Hello World service. Part 2 describes the Spring DM product and adding Spring to OSGi. And Part 3 covers several web deployment scenarios and issues. Also, Joseph Ottinger h