JBoss Microcontainer. The configuration defines MC beans for the framework itself and its associated deployers.
The OSGiBootstrap provides an OSGiFramework through a OSGiBootstrapProvider.
A OSGiBootstrapProvider is discovered in two stages
- Read the bootstrap provider class name from a system property
- Read the bootstrap provider class name from a resource file
In both cases the key is the fully qalified name of the
The following code shows how to get the default OSGiFramework from the OSGiBootstrapProvider.
OSGiBootstrapProvider boot = OSGiBootstrap.getBootstrapProvider();The OSGiBootstrapProvider can also be configured explicitly. The OSGiFramework is a named object from the configuration.
OSGiFramework fw = boot.getFramework();
Bundle bundle = fw.getSystemBundle();
OSGiBootstrapProvider boot = OSGiBootstrap.getBootstrapProvider();The JBossOSGi SPI comes with a OSGiBootstrapProvider that uses a JBoss Microcontainer bean configuration.
OSGiFramework fw = boot.getFramework("MyOSGiFramework");
Bundle bundle = fw.getSystemBundle();
OSGiBootstrapProvider implementations that read their configurtation from some other source are possible, but currently not part of the JBossOSGi SPI.
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.
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
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)
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.
Management ViewThe ManagedFramework
The ManagedFramework gives you access to the MBean views of the deployed Bundles. It is registerd under the name:
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 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.