Friday, March 27, 2009

JBossOSGi - Service Provider Interface

This is the second of a the current series of three blogs on JBossOSGi
  1. Getting Started
  2. Service Provider Interface
  3. Provided Services
The JBossOSGi Service Provider Interface (SPI) is the integration point between the supported OSGi Frameworks and theJBoss Microcontainer. The configuration defines MC beans for the framework itself and its associated deployers.


The latest version of the JBossOSGi SPI JavaDoc is published online as part of the JBossOSGi Hudson QA Environment.

Bootstrapping JBossOSGi

The OSGiBootstrap provides an OSGiFramework through a OSGiBootstrapProvider.

A OSGiBootstrapProvider is discovered in two stages

  1. Read the bootstrap provider class name from a system property
  2. Read the bootstrap provider class name from a resource file

In both cases the key is the fully qalified name of the org.jboss.osgi.spi.framework.OSGiBootstrapProvider interface.

The following code shows how to get the default OSGiFramework from the OSGiBootstrapProvider.

OSGiBootstrapProvider boot = OSGiBootstrap.getBootstrapProvider();
OSGiFramework fw = boot.getFramework();
Bundle bundle = fw.getSystemBundle();

The OSGiBootstrapProvider can also be configured explicitly. The OSGiFramework is a named object from the configuration.

OSGiBootstrapProvider boot = OSGiBootstrap.getBootstrapProvider();
boot.configure(configURL);

OSGiFramework fw = boot.getFramework("MyOSGiFramework");
Bundle bundle = fw.getSystemBundle();
The JBossOSGi SPI comes with a OSGiBootstrapProvider that uses a JBoss Microcontainer bean configuration.

OSGiBootstrapProvider implementations that read their configurtation from some other source are possible, but currently not part of the JBossOSGi SPI.

Using the SPI from within JBossAS deployed components

If you need access to the OSGi Framework from within an JBossAS deployed component (e.g. servlet, ejb, mbean) you would not bootstrap JBossOSGi through the SPI. Instead, you would inject the already bootstrapped OSGi Framework instance into your component.

Bundle Deployers

JBossOSGi comes with a number of JBoss Microcontainer based deployers. Each deployer takes care of a specific aspect of bundle deployment.
  • BundleMetaDataDeployer - Create BundleMetaData from Manifest Headers
  • BundleRealDeployer - Installs the Bundle into the Framework's SystemContext
  • BundleClassLoaderDeployer - Creates a BundleClassLoader for the deployed Bundle
  • BundleStartStopDeployer - Starts the Bundle when dependencies are resolved
  • BundleManagementDeployer - Register the Bundle as MBean with JMX
BundleMetaDataDeployer

The BundleMetaDataDeployer creates the BundleMetaData from Manifest Headers. If the manifest does not contain a header named Bundle-SymbolicName this deployer does nothing.

BundleRealDeployer

The BundleRealDeployer installs the Bundle into the Framework's SystemContext. Optionally you can configure a list of bundle locations that should be skipped and hence not installed. Typically, these bundles are already installed during Framework startup.

On undeploy the Bundle gets uninstalled from the Framework's SystemContext.

BundleClassLoaderDeployer

The BundleClassLoaderDeployer attaches a ClassLoaderFactory that creates a BundleClassLoader for the deployed Bundle. A BundleClassLoader delegates all classloading concerns to the underlying Bundle.

BundleStartStopDeployer

The BundleStartStopDeployer currently works in two modes:

  • deferredStart (default)
  • simpleStart

In mode deferredStart the Bundle is added to a list of unresolved Bundles, which then get passed on to PackageAdmin.resolveBundles(Bundle[]). The deployer then iterates over the unresolved Bundles and only starts those Bundles that are in state RESOLVED. In this mode Bundles can be deployed in any order and only get started when all their respective dependencies can be resolved.

In mode simpleStart the deployer attempts to start the Bundle regardless of whether its dependencies can get resolved. In case the Bundle has a dependency oin a package that is not yet available, deployment will fail. In this mode Bundles must be deployed in the order required to start them.

The start mode is a configurable property on the Framework's SystemContext.

BundleManagementDeployer

The BundleManagementDeployer registers the Bundle as StandardMBean with JMX. Please see the section on Management View for details.

Management View

JBossOSGi registers the Framework and every deployed Bundle with the JMX MBeanServer.

The ManagedFramework

The ManagedFramework gives you access to the MBean views of the deployed Bundles. It is registerd under the name:

jboss.osgi:service=ManagedFramework
The ManagedBundle

The ManagedBundle gives you access to the MBean views of a deployed Bundle. It is registerd under the name:

jboss.osgi:bundle=[SymbolicName],id=[BundleId]
Accessing the Management Objects

If you work with the JBossOSGi Testsuite you get access to the Managed Objects through the JBossOSGi SPI provided JUnit support package org.jboss.osgi.spi.junit.

If you install JBossOSGi in an already existing JBossAS instance you also get access to the Managed Objects through the JBoss provided JMX Console (http://localhost:8080/jmx-console).



The JMX Console is not part of the JBossOSGi Runtime.

What is there to come?

The intention of this post was to provide information the JBossOSGi SPI.

In my next post I'm going to write about the JBossOSGi Provided Services - stay tuned.

1 comment:

  1. Using the SPI from within JBossAS deployed components:
    I'm struggeling to do that. How do I inject the framework into a ejb / tomcat container?

    ReplyDelete