JBoss OSGi Diary

JBoss AS7 OSGi Presentation + Demo

2011-08-04T11:25:00.004+02:00

I am happy to announce that the JBoss AS7 OSGi webinar recording is now available on vimeo.

JBoss AS7 is a game-changer for both Java EE developers as well as application server administrators. And while JBoss is best known for being a Java EE container, in this session, we will focus on the OSGi capabilities of the new JBoss AS7.

Starting with background information on OSGi in general, Thomas Diesler introduces the main objectives of this technology and explains the unique JBoss OSGi vision. Combining the best of two worlds we show how modern Java EE applications on AS7 can use the OSGi component model and vice versa.

Presenters: Thomas Diesler and David Bosschaert

Thomas is the OSGi Project Lead at JBoss. As the Red Hat representative in the OSGi Enterprise Expert Group he is involved in the standardization effort of various OSGi technologies that are relevant to the enterprise space.

David, principal software engineer at Red Hat, is a co-chair of the OSGi Enterprise Expert Group and spends the majority of his time on the JBoss OSGi framework and other open source projects. Before joining JBoss/Red Hat in 2010, David worked for IONA Technologies and Progress Software in Dublin, Ireland.

The demo code is available here.

JBossOSGi-1.0.0 Final Released

2011-07-26T13:24:00.004+02:00

I am happy to announce the release of JBossOSGi-1.0.0 Final.

You can download the binary here: jboss-osgi-installer-1.0.0.jar

This is our first OSGi Core 4.2. Framework compliant release. It also comes with improvements in the following areas

Integration with JBoss AS7
Pass the Core 4.2 Compliance Testsuite from the OSGi Alliance
Add Declarative Services (DS) example
Documentation now available in Confluence
OSGi service invocation from EJB3 and Webap
Migration to the Arquillian test framework
Better support for execution environments

For details please have a look at the latest version of our User Guide.

Here are the change log details

JBossOSGi 1.0.0

Bug

[JBOSGI-438] - Exception when starting Blueprint component
[JBOSGI-443] - Intermittent WebAppNegativeTestCase failure
[JBOSGI-458] - Warning from webconsole at first access

Feature Request

[JBOSGI-192] - Access an OSGi service from EJB3
[JBOSGI-313] - OSGi service invocation from EE6 WebApp
[JBOSGI-474] - Add Dynamic Services to examples and distro

Task

[JBOSGI-434] - Release 1.0.0 Final
[JBOSGI-448] - Run OSGi integration tests as part of the AS7 Hudson job
[JBOSGI-461] - Update user guide with OSGi in AS7 usage
[JBOSGI-463] - Create OSGi in AS7 QuickStart guide
[JBOSGI-468] - Update to Arquillian 1.0.0.CR1 or later
[JBOSGI-469] - Migrate performance tests to new Arquillian API
[JBOSGI-471] - Remove JTA support for standalone Runtime
[JBOSGI-472] - Migrate documentation to confluence
[JBOSGI-481] - Fix Equinox performance tests

Core Framework 1.0.0

Bug

[JBOSGI-433] - [TCK] Intermittent StartLevelControl failure
[JBOSGI-439] - Bundle resolution error should provide reason
[JBOSGI-442] - Circular class load issue on lazy activation
[JBOSGI-444] - Service event failure on Runtime shutdown
[JBOSGI-450] - Bundle containing a BundleTracker causes subsequent bundle install/starts to fail
[JBOSGI-451] - Timeout starting Framework after shutdown
[JBOSGI-452] - ConcurrentModificationException in BundleManager.getBundles()
[JBOSGI-456] - Framework events may get delivered out of order
[JBOSGI-465] - Framework sets service mode while Container is shutting down
[JBOSGI-473] - Unsupported execution environment [OSGi/Minimum-1.2, CDC-1.1/Foundation-1.1, J2SE-1.4] we have [J2SE-1.5, , JavaSE-1.6]
[JBOSGI-476] - Cannot acquire start/stop lock for lazy bundles
[JBOSGI-477] - Unsupported execution environment OSGi/Minimum-1.1

Feature Request

[JBOSGI-441] - Allow for OSGi style Class Filtering

Task

[JBOSGI-238] - [TCK] Framework core functionality
[JBOSGI-255] - [TCK] Core Framework
[JBOSGI-455] - Add services that represent the RESOLVED and ACTIVE states

Enjoy

JBoss AS7 OSGi Integration

2010-11-11T17:50:00.014+01:00

Now that JBossAS-7.0.0.Alpha1 has come out I'd like to talk about how JBoss OSGi integrates with it and what benefits our community will gain from the OSGi integration. In this post I'll show how non-OSGi components like EJB3, Servlet, CDI Beans, ManagedBeans, MBeans, etc. can access OSGi services and vice versa.

OSGi in the EE Landscape

Generally I believe that OSGi is very much an all-or-nothing technology. If your application is an OSGi bundle (or many of them) you must run within an OSGi Framework and can only have access to services that are provided by other OSGi bundles. In todays EE appplication landscape where folks take (standard) functionality like JPA, Servlet3, CDI, EJB3, JCA, JMS, etc for granted they would need a container that offers these services not only to EE applications but also to OSGi bundles.

In Mar-2010 the OSGi Enterprise Expert Group, has come up with its first EE OSGi specification, which IMHO offers a fraction of what we currently see in modern EE applications. There is no JSP, EJB3, JCA, JMS, CDI not even Annotation processing. The EEG is working on completing the picture, but this is unlikely to become generally available in the near future. David and I are members of this group, so its partially also our call.

Of course, if your application is such that it only requires what is available in OSGi Core, Compendium and Enterprise already (and many of todays larger OSGi applications do) OSGi is a good candidate to solve general modularity and service integration issues.

The JBoss approach to OSGi

At JBoss we take a different approach. With the upcoming AS7 the basic building block is a "module" which can have dependencies on other modules. There are services with basic lifecycle that can also have dependencies on each other. Our OSGi Framework implementation builds on top of this basic infrastructure like any other JBoss subsystem. We integrate at the lowest possible level. Such it becomes possible to access an OSGi service from a non-OSGi component and vice versa.

The questions about the suitability of OSGi is at the very heart of these integration issues IMHO. If EJB3, CDI, etc. offer value-add then it must be possible to leverage that value from an OSGi application. Otherwise you have an either/or situation where you gain benefits from one technology but at the same time loose benefits from another technology that cannot be accessed any more.

You can think of this in terms of two intersecting sets of technology (i.e. EE6, OSGi). I'm interested in the superset of the two and not so much in the smaller individual sets. The aim is that JBoss users who already write great and non trivial EE applications can now "also" use OSGi to address modularity issues in these very applications.

The Theory behind JBoss OSGi

Any deployment, and in-fact any jar you see in AS7, is a Module. A Module may have dependencies and a number of attached ResourceLoaders. A ResourceLoader is typically backed by a VirtualFile. A Module can choose to export a subset of the resource paths from its attached ResourceLoaders. This is equivalent to the Export-Package notion in OSGi. The dependencies on other Modules are equivalent to Require-Bundle. A module can choose which paths to import from a given dependency. A Module can choose to re-export the paths that it imports from a dependency.

An OSGi Bundle is a jar with a set of metadata in it's Manifest. To name a few, we have

Generally speaking however, these are Requirements and Capabilities that a Bundle may have. In JBoss OSGi we translate the OSGi metadata to these general Requirements and Capabilities and feed the Standalone Resolver with it. At bundle resolution time, the Resolver tries to find a consistent set of Wires, such that every non-optional Requirement is wired to a Capability. This is a non-trivial process that leads to consistent class spaces. If successful, the Bundle is said to be RESOLVED.

At the end of the day, every OSGi Framework conceptually creates dependencies between the installed bundles and limits the set of paths at the exporting and importing side of the wires.

So we get the set of Requirements and Capabilities from somewhere, feed them to our resolver abstraction and finally use the resulting Wires to setup the ModuleSpec. The source for our Requirements and Capabilities is not limited to the OSGi manifest. Any AS7 deployment can generate resolver metadata and make itself known to the OSGi layer.

At deploy time every Bundle becomes an AS7 Module and every AS7 Module may become an OSGi Bundle when its provides it's set of resolver metadata and registers with the OSGi layer. OSGi bundles are therefore a subset of the modules that exist in the AS7 module layer.

Lets look at some code ...

Bundle accessing a Non-OSGi Module

In a test case we construct and deploy a module that provides a simple Echo service to the running AS7.

JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "example-xservice-target-module");
archive.addClasses(Echo.class, EchoService.class, TargetModuleActivator.class);
String activatorPath = "META-INF/services/" + ServiceActivator.class.getName();
archive.addResource(getResourceFile("xservice/target-module/" + activatorPath), activatorPath);

The module contains a few classes and a ServiceActivator. The ServiceActivator is the equivalent of a BundleActivator. When the module gets activated we register a simple EchoService.

public static void addService(BatchBuilder batchBuilder)
{
  serviceBuilder = batchBuilder.addService(SERVICE_NAME, new EchoService());
  serviceBuilder.addAliases(ServiceName.of(Constants.JBOSGI_PREFIX, Echo.class.getName()));
  serviceBuilder.setInitialMode(Mode.ACTIVE);
  log.infof("Service added: %s", SERVICE_NAME);
}

Please note, that the service is also registered with an alias. The JBoss OSGi service registry uses the ServiceContainer that contains all services that exist in AS7. For service lookup the OSGi API uses the FQN of an interface that the requested service implements. The alias is needed for this OSGi API call to succeed

ServiceReference sref = context.getServiceReference(Echo.class.getName());
Echo service = (Echo)context.getService(sref);
service.echo("hello world");

When the module is deployed, it is not automatically registered with the OSGi layer. A bundle that imports the package of the Echo interface would not resolve.

Any module can however be registered with the OSGi layer.

ModuleIdentifier moduleId = ModuleIdentifier.create("deployment.example-xservice-target-module");
registerModuleWithBundleManager(moduleId);

Currently this must be done explicitly - there is no automatic registration. In our case the module does not provide resolver metadata explicitly, so it will be generated. We add a PackageCapability for every exported path.

ResolverPlugin resolverPlugin = getPlugin(ResolverPlugin.class);
XModuleBuilder builder = resolverPlugin.getModuleBuilder();
builder.createModule(symbolicName, version, 0);
builder.addBundleCapability(symbolicName, version);
for (String path : module.getExportedPaths())
{
  if (path.startsWith("META-INF"))
    continue;

  String packageName = path.replace('/', '.');
  builder.addPackageCapability(packageName, null, null);
}
XModule resModule = builder.getModule();

Now that the module is known to the OSGi layer. The resolver can use the module's capabilities for bundle resolution. We can now install and start a real OSGi bundle that imports the echo package and calls the Echo service in its BundleActivator.

mvn -Dtarget.container=jboss70x -Dtest=BundleAccessesModuleServiceTestCase test

Running org.jboss.test.osgi.example.xservice.BundleAccessesModuleServiceTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.009 sec

17:21:16,469 INFO  Activating deployment: example-xservice-target-module
17:21:16,732 INFO  Service added: service jboss.osgi.xservice.target
17:21:16,733 INFO  ModuleIdentifier: module:deployment.example-xservice-target-module:main
17:21:16,854 INFO  Install bundle: deployment.example-xservice-target-module:0.0.0
17:21:18,135 INFO  Install bundle: example-xservice-client-bundle:1.0.0
17:21:18,196 INFO  Echo: hello world
17:21:18,199 INFO  Bundle started: example-xservice-client-bundle:1.0.0
17:21:18,222 INFO  Bundle uninstalled: example-xservice-client-bundle:1.0.0
17:21:18,235 INFO  Bundle uninstalled: deployment.example-xservice-target-module:0.0.0
17:21:18,292 INFO  Undeployed example-xservice-target-module

Going forward, we can now define a set of rules for every possible AS7 deployment on whether or not it gets registered with the OSGi layer and how it generates it's caps/reqs.

A possible question could be:

"Why isn't the target module a real OSGi bundle in the first place? In other words, why does it not define its capabilities in a standard way in the OSGi manifest"

The target module may have dependencies on other services that are not available in the OSGi layer. Or simply because the folks that provide the target module do not feel sufficiently familiar with OSGi. The important thing here is that with AS7 we have a migration path to and from OSGi.

Module accessing an OSGi Service

This scenario requires a little more thought. Let's first explore the seemingly obvious approach.

The target bundle contains the Echo interface
The client module has a dependency on the target bundle

Every Module has a ModuleIdentifier, which in case of an OSGi bundle is constructed according to the following pattern

jbosgi.[bundle-symbolic-name]:[bundle-version]

In case of the target bundle that is used in this test case, we would have

jbosgi.example-xservice-target-bundle:1.0.0

This is the Require-Bundle semantic, which is generally considered bad practise in OSGi. In the OSGi core spec we find the following chapter

3.12.3 Issues With Requiring Bundles

The preferred way of wiring bundles is to use the Import-Package and
Export-Package headers because they couple the importer and exporter to a
much lesser extent. Bundles can be refactored to have a different package
composition without causing other bundles to fail.

The Require-Bundle header provides a way for a bundle to bind to all the
exports of another bundle, regardless of what those exports are. Though this
can seem convenient at first, it has a number of drawbacks:

Split Packages – Classes from the same package can come from different bundles with Require bundle, such a package is called a split package. Split packages have the following drawbacks:

Completeness – Split packages are open ended, it is difficult to guarantee that all the intended pieces of a split package have actually been included.
Ordering – If the same classes are present in more than one required bundle, then the ordering of Require-Bundle is significant. A wrong ordering can cause hard to trace errors, similar to the traditional class path model of Java.
Performance – A class must be searched in all providers when packages are split. This potentially increases the number of times that a ClassNotFoundException must be thrown which can potentially introduce a significant overhead.
Confusing – It is easy to find a setup where there is lots of potential for confusion. For example, the following setup is non-intuitive.
```
A: Export-Package: p;uses:=q
   Import-Package: q
B: Export-Package: q
C: Export-Package: q
D: Require-Bundle: B, C
   Import-Package: p
```
In this example, bundle D merges the split package q from bundles B and
bundle C, however, importing package p from bundle A puts a uses constraint on package p for package q. This implies that bundle D can see the valid package q from bundle B but also the invalid package q from bundle C. This wiring is allowed because in almost all cases there will be no problem. However, the consistency can be violated in the rare case when package C.q contains classes that are also in package B.q.

Mutable Exports – The feature of visibility:=reexport that the export signature of the requiring bundle can unexpectedly change depending on the export signature of the required bundle.

Shadowing – The classes in the requiring bundle that are shadowed by those in a required bundle depend on the export signature of the required bundle and the classes the required bundle contains. (By contrast, Import-Package, except with resolution:=optional, shadows whole packages regardless of the exporter.)

Good practise is to use Export-Package to declare a PackageCapability and Import-Package to declare a PackageRequirement. In this way importer does not need to care where a package comes from and the provider of the exported package is free to move the package around from one bundle to another without breaking the importer.

OSGi supports the notion of bundle revisions. This does not show up in the public API. However, every time a bundle is updated (i.e. the bytes change) the framework creates a new revision with potentially the same Bundle-SymbolicName and Bundle-Version. Internally we append the revision suffix to the ModuleIdentifier. As a consequence, binding to a particular ModuleIdentifier identifier ultimately means binding to a particular revision, which negates the purpose update.

Having said all this, we decide against putting the Echo interface (i.e. the API) in the target bundle. Instead we put it in a Module which can be registered with the OSGi layer as described above.

JavaArchive getAPIModuleArchive() throws Exception
{
  JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "example-xservice-api-module");
  archive.addClasses(Echo.class);
  archive.addDirectory("META-INF");
  return archive;
}

// Deploy the module that contains the API
String apiDeploymentName = getRemoteRuntime().deploy(getAPIModuleArchive());

// Register the API module with the OSGi layer
ModuleIdentifier apiModuleId = ModuleIdentifier.create("deployment." + apiDeploymentName);
registerModuleWithBundleManager(apiModuleId);

The target bundle is a plain OSGi bundle that imports the package of the Echo service and registers an instance of that service with the OSGi service registry.

@Override
   public void start(final BundleContext context) throws Exception
   {
      context.registerService(Echo.class.getName(), new EchoImpl(), null);
   }

   static class EchoImpl implements Echo
   {
      @Override
      public String echo(String message)
      {
         log.infof("Echo: %s", message);
         return message;
      }
   }

The client module needs to define a dependency on the API module. In JBoss AS module dependencies can be defined in the manifest like this

Manifest-Version: 1.0
Dependencies: org.osgi.core,deployment.example-xservice-api-module

Ouch, this uses an AS7 proprietary manifest header as well as Require-Bundle semantics. For AS7 internal modules (i.e. the ones that we control) this direct and hard coded approach is key to bootstrap performance. It should however be carefully considered before putting in user deployments.

Never mind, for sake of this exercise we continue. When the client module activates it registers a Service.

public class EchoInvokerService implements Service<Void>
{
   InjectedValue<BundleContext> injectedBundleContext = new InjectedValue<BundleContext>();

   static void addService(BatchBuilder batchBuilder)
   {
      EchoInvokerService service = new EchoInvokerService();
      BatchServiceBuilder serviceBuilder = batchBuilder.addService(SERVICE_NAME, service);
      serviceBuilder.addDependency(ServiceName.parse("jboss.osgi.context"), BundleContext.class, service.injectedBundleContext);
      serviceBuilder.setInitialMode(Mode.ACTIVE);
      log.infof("Service added: %s", SERVICE_NAME);
   }

   @Override
   public void start(StartContext context) throws StartException
   {
      BundleContext systemContext = injectedBundleContext.getValue();
      ServiceReference sref = systemContext.getServiceReference(Echo.class.getName());
      Echo service = (Echo)systemContext.getService(sref);
      service.echo("hello world");
   }

   @Override
   public void stop(StopContext context)
   {
   }

   @Override
   public Void getValue() throws IllegalStateException
   {
      return null;
   }
}

This is a native AS7 service that gets the OSGi system BundleContext injected before it is started. Currently, when you download and try jboss-7.0.0.Alpha1 you will see that it bootstraps in very little time (i.e. less than 3sec). This is also because the OSGi subsystem is activated lazily. Installing a service like the one above with initial mode ACTIVE would cause all services that it depends on also to become ACTIVE. The OSGi subsystem would activate and the framework would start.

In the start method of the EchoInvokerService you see the usage of OSGi API that calls the target service.

mvn -Dtarget.container=jboss70x -Dtest=ModuleAccessesBundleServiceTestCase test

Running org.jboss.test.osgi.example.xservice.ModuleAccessesBundleServiceTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.009 sec

11:10:22,040 INFO  Activating deployment: example-xservice-api-module
11:10:22,228 INFO  Install bundle: deployment.example-xservice-api-module:0.0.0
11:10:23,140 INFO  Install bundle: example-xservice-target-bundle:1.0.0
11:10:23,251 INFO  ModuleIdentifier: module:jbosgi.example-xservice-target-bundle:1.0.0
11:10:23,252 INFO  Bundle started: example-xservice-target-bundle:1.0.0
11:10:23,413 INFO  Activating deployment: example-xservice-client-module
11:10:23,516 INFO  Service added: service jboss.osgi.xservice.invoker
11:10:23,518 INFO  ModuleIdentifier: module:deployment.example-xservice-client-module:main
11:10:23,520 INFO  Echo: hello world
11:10:23,602 INFO  Undeployed example-xservice-client-module
11:10:23,661 INFO  Bundle uninstalled: example-xservice-target-bundle:1.0.0
11:10:23,687 INFO  Bundle uninstalled: deployment.example-xservice-api-module:0.0.0
11:10:23,739 INFO  Undeployed example-xservice-api-module

Conclusion

I have shown how in principle an OSGi bundle can access an arbitrary AS7 service and vice versa. With this distribution we have reached about 80% OSGi Core TCK compliance, which we hope to complete by Q2/2011. The final version of AS7 is currently scheduled for May/2011.

I am hopeful that by the time AS7 goes final we have examples of various EE components interacting with OSGi and vice versa. The aim is that you can use the benefits of OSGi modularity and its service layer in non-trivial applications that make use of AS7 middle ware.

You may also want to check out David's post on "Using OSGi in JBoss AS7".

May this be useful
-thomas

JBossOSGi Hudson on Amazon Elastic Cloud

2010-10-26T11:35:00.014+02:00

Following Amazons announcement for an AWS Free Usage Tier, I thought I would give it a try. Here my account.

Creating the Instance

If you are new to Amazon EC2 you need to create an account and sign in. Once you are in the AWS Management Console, you can create a key pair like this

I like to have control over the connection ports that are accessible on my instance, so I create a new Security Group, which I can later use with my instance.

Next, you navigate to Instances and launch an new Amazon Linux Micro instance. Basic 32-bit Amazon Linux is a good choice because it can be upgraded to small. A 64-bit instance can only be upgraded to large and above.

Select the key and security group that you created earlier, hit launch and your Linux Micro instance should be up and running.

Accessing you Linux Instance

When you created your keypair you were offered to download and save the private key to a secure location. You can now ssh into you newly created instance like this

chmod 600 .ssh/tdiesler-ec2.pem
ssh -i .ssh/tdiesler-ec2.pem ec2-user@ec2-50-16-7-151.compute-1.amazonaws.com
Last login: Mon Oct 25 13:32:07 2010 from p5b04e10a.dip.t-dialin.net

       __|  __|_  )  Amazon Linux AMI
       _|  (     /     Beta
      ___|\___|___|

See /etc/image-release-notes for latest release notes. :-)
[ec2-user@ip-10-112-99-96 ~]$

Installing Hudson on Tomcat

Amazon Liunx supports the Yum Package Manager, which I happen to know quite well because I run Fedora. Lets first check if Tomcat is there

$ yum list installed | grep tomcat
$

Ok, that's not the case, so see what's available.

$ yum list available | grep tomcat
...
tomcat6.noarch                               6.0.24-8.12.amzn1 
tomcat6-admin-webapps.noarch                 6.0.24-8.12.amzn1 
tomcat6-docs-webapp.noarch                   6.0.24-8.12.amzn1 
tomcat6-javadoc.noarch                       6.0.24-8.12.amzn1 
tomcat6-log4j.noarch                         6.0.24-8.12.amzn1 
tomcat6-webapps.noarch                       6.0.24-8.12.amzn1

Let's install tomcat6

[ec2-user@ip-10-112-99-96 ~]$ 
$ sudo yum install tomcat6
...
Installed:
  tomcat6.noarch 0:6.0.24-8.12.amzn1
...
Complete!

Furthermore, we need Git, Ant and Maven. Git and Ant we can install with yum like above. Maven however does not seem to be available in yum. So lets get it from the Apache Maven download page.

$ wget http://apache.linux-mirror.org/maven/binaries/apache-maven-3.0-bin.zip
...
2010-10-25 14:40:23 (44.4 KB/s) - “apache-maven-3.0-bin.zip” saved [2919967/2919967]
$ unzip apache-maven-3.0-bin.zip
$ sudo mkdir /usr/java
$ sudo mv apache-maven-3.0 /usr/java
$ sudo ln -s /usr/java/apache-maven-3.0 /usr/java/apache-maven
$ mkdir bin
$ ln -s /usr/java/apache-maven/bin/mvn bin/mvn
$ mvn
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.108s
[INFO] Finished at: Mon Oct 25 14:44:26 UTC 2010
[INFO] Final Memory: 2M/7M
[INFO] ------------------------------------------------------------------------

Amazon Linux comes with openjdk, which is fine for most purposes. At the time of this writing however, I saw issues with the maven build and Hudson Captcha. So lets install the Oracle JDK

$ cd /usr/java
$ sudo wget http://cds.sun.com/is-bi/...jdk-6u22-linux-i586.bin
$ sudo chmod +x jdk-6u22-linux-i586.bin 
$ sudo ./jdk-6u22-linux-i586.bin 
$ sudo ln -s jdk1.6.0_22 jdk1.6
$ sudo rm jdk-6u22-linux-i586.bin

$ vi ~/.bash_profile
...
export JAVA_HOME="/usr/java/jdk1.6"
export PATH=$HOME/bin:$JAVA_HOME/bin:$PATH

$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

Building JBoss OSGi

The JBoss OSGi umbrella project that holds the Hudson setup as an integral part of the code base is hosted on GitHub.

$ mkdir git; cd git
$ git clone git://github.com/jbosgi/jbosgi.git; cd jbosgi
$ git submodule init
$ git submodule update

JBoss community projects often do not contain the JBoss Nexus Configuration. Follow the instructions on Maven Getting Started - Users to setup your ~/.m2/settings.xml

Now, lets build the umbrella for the first time

$ mvn install
...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] JBossOSGi JMX ..................................... SUCCESS [1:00.822s]
[INFO] JBossOSGi JMX API ................................. SUCCESS [1:44.154s]
[INFO] JBossOSGi VFS ..................................... SUCCESS [0.008s]
[INFO] JBossOSGi VFS API ................................. SUCCESS [5.442s]
[INFO] JBossOSGi SPI ..................................... SUCCESS [24.504s]
[INFO] JBossOSGi JMX Bundle .............................. SUCCESS [15.142s]
[INFO] JBossOSGi JMX iTests .............................. SUCCESS [2:37.160s]
[INFO] JBossOSGi VFS VFS30 ............................... SUCCESS [9.390s]
[INFO] JBossOSGi Deployment .............................. SUCCESS [12.598s]
[INFO] JBossOSGi Framework ............................... SUCCESS [0.047s]
[INFO] JBossOSGi Framework Core .......................... SUCCESS [32.110s]
[INFO] JBossOSGi Framework iTest ......................... SUCCESS [2:33.963s]
[INFO] JBossOSGi ......................................... SUCCESS [0.026s]
[INFO] JBossOSGi Reactor ................................. SUCCESS [0.006s]
[INFO] JBossOSGi Testsuite ............................... SUCCESS [0.017s]
[INFO] JBossOSGi Testsuite Examples ...................... SUCCESS [3:39.319s]
[INFO] JBossOSGi Testsuite Functional .................... SUCCESS [1:40.045s]
[INFO] JBossOSGi Testsuite Performance ................... SUCCESS [19.179s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 16:48.812s
[INFO] Finished at: Tue Oct 26 12:30:18 UTC 2010
[INFO] Final Memory: 22M/68M
[INFO] ------------------------------------------------------------------------

This will take a while, so lets continue with Tomcat and Hudson.

Installing Hudson

In our security group we opened port 8280. Tomcat however runs on 8080 by default. Lets change that.

$ sudo vi /etc/tomcat6/server.xml 
...
    <connector port="8280" connectiontimeout="20000" 
        protocol="HTTP/1.1" redirectport="8443">

Now we configure tomcat to run as the ec2-user, which allows Hudson to reuse the ec2-user's maven repository. HUDSON-HOME can also be set in the same config file.

$ sudo vi /etc/tomcat6/tomcat6.conf
...
# Where your java installation lives
JAVA_HOME="/usr/java/jdk1.6"

# Where HUDSON has its home
HUDSON_HOME=/usr/share/tomcat6/workspace/hudson-home

# What user should run tomcat
TOMCAT_USER=ec2-user

Make sure the ec2-user is in the 'tomcat' group so it can write files to HUDSON_HOME during setup.

$ sudo usermod -g tomcat ec2-user
$ mkdir -p /usr/share/tomcat6/workspace/hudson-home

You might need to re-login for the initial login group change to take effect.

JBossOSGi simplifies Hudson setup a great deal, by including configuration and jobs in it codebase. This also allows us to recreate the QA environment for any given version by running a simple Ant task.

$ cd git/jbosgi/hudson
$ cp ant.properties.example ant.properties
$ ant hudson-setup
...
init-hudson:
     [echo] hudson.home = /usr/share/tomcat6/workspace/hudson-home
...
get-hudson:
      [get] Getting: http://hudson-ci.org/download/war/1.382/hudson.war
      [get] Getting: http://hudson-ci.org/download/plugins/github/0.2/github.hpi
      [get] Getting: http://hudson-ci.org/download/plugins/git/1.1/git.hpi
...
hudson-tomcat-setup:
     [copy] Copying 1 file to /usr/share/tomcat6/workspace/hudson-home/plugins
     [copy] Copying 1 file to /usr/share/tomcat6/workspace/hudson-home/plugins

hudson-setup:
     [copy] Copying 2 files to /usr/share/tomcat6/workspace/hudson-home
     [copy] Copying 9 files to /usr/share/tomcat6/workspace/hudson-home/jobs
     [echo] 
     [echo] *************************************
     [echo] * Hudson setup successfully          
     [echo] * sudo service tomcat6 restart       
     [echo] *************************************

$ sudo service tomcat6 restart
Stopping tomcat6:                                          [  OK  ]
Starting tomcat6:                                          [  OK  ]

Now we should be able to connect to the running Hudson instance.

Hudson Security

By default, Hudson is setup with strict project based security. Only the 'ec2-user' or whoever you configured in ${hudson.admin} can modify the configuration and run the jobs. Lets sign-up as ec2-user

You should now be able to run the jobs.

Upgrading the Instance Type

The Amazon free offer is limited to Micro instances. With it's 613MB of RAM not surprisingly it turns out that this is not sufficient to run the JBossOSGi QA in an acceptable time.

This is however not a problem, because the instance can be stopped and it's type can be changed to m1.small or m1.large depending on what you are willing to pay.

$ ec2-stop-instances i-10429a7d
$ ec2-modify-instance-attribute --instance-type=m1.large i-10429a7d
$ ec2-start-instances i-10429a7d

Note, that this can only be done with instances that are backed by the Elastic Block Store.

Creating an Elastic IP

Every time you stop/start an EC2 instance it's public DNS entry changes. Amazon's solution to this is the Elastic IP. You pay for the IP when your instance is not connected.

This IP address can be associated with your favorite domain name. In our case its a dyndns.org forward. So what was formerly known as

http://jbmuc.dyndns.org:8280/hudson

now points to the EC2 instance that we've just setup.

May this be useful
-thomas

JBossOSGi 1.0.0.Beta9 released

2010-09-27T10:47:00.003+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta9.

You can download the binary here: jboss-osgi-installer-1.0.0.Beta9.jar

The release comes with improvements in the following areas

Uses the new JBoss Modules modularity layer, which is also the basis of AS7
Performance increase by approximately 2000%
Integration with upcoming JBoss Application Server 7
Support for update bundles and refresh packages
Improved resolver abstraction/integration
Migration to the Arquillian test framework

For details please have a look at the latest version of our User Guide.

Here are the change log details

Bug

[JBOSGI-331] - Activator cannot change bundle start level
[JBOSGI-339] - Fragment failures in functional runtime tests
[JBOSGI-346] - Attached fragment hides private package in host
[JBOSGI-354] - Initial Bundle Start Level initialization is done in the wrong place.
[JBOSGI-356] - JBoss OSGi has implicit imports
[JBOSGI-367] - JTA BundleActivator cannot find DocumentBuilderFactory
[JBOSGI-373] - Cannot load service through java.util.ServiceLoader
[JBOSGI-383] - Cannot refresh uninstalled bundle through FrameworkMBean
[JBOSGI-387] - Potential problem with refreshing uninstalled bundles via JMX

Feature Request

[JBOSGI-209] - Implement resolver preferences
[JBOSGI-376] - Initial OSGi / Modules dependency implementation
[JBOSGI-380] - Initial Arquillian test integration
[JBOSGI-386] - Invoking Refresh Packages on the framework from Web Console causes issues

Task

[JBOSGI-258] - [TCK] Start Level
[JBOSGI-336] - Implement PackageAdmin.refreshPackages(Bundle[])
[JBOSGI-343] - Comprehensive PackageAdmin test coverage
[JBOSGI-359] - Comprehensive Bundle API test coverage
[JBOSGI-360] - Integrate jbosgi-container into jbosgi umbrella
[JBOSGI-361] - TCK setup for MSC Core Framework
[JBOSGI-362] - Integrate the MSC Framework with the Installer
[JBOSGI-363] - Update resolver to Apache Felix-3.0.x
[JBOSGI-369] - Add support for fragments to Package Admin
[JBOSGI-374] - Release 1.0.0.Beta9
[JBOSGI-375] - Restore fragment, native code, service hook support
[JBOSGI-378] - OSGi Performance Analysis
[JBOSGI-379] - Implement Bundle.update()
[JBOSGI-388] - Migrate all remaining Husky tests to Arquillian

Sub-task

[JBOSGI-241] - [TCK] Framework classpath
[JBOSGI-244] - [TCK] Framework filter
[JBOSGI-247] - [TCK] Framework service hooks
[JBOSGI-248] - [TCK] Framework lifecycle
[JBOSGI-251] - [TCK] Framework services
[JBOSGI-252] - [TCK] Framework bundle listener

Enjoy

Standalone OSGi Resolver

2010-07-27T02:56:00.006+02:00

When designing complex software system, modularity in one of the key aspects that folks have in mind. When I say "complex" I mean more than a handful of subsystems that evolve with individual life cycles and are developed by possibly geographically disconnected teams. Key to success are well defined integration points that also have the flexibility to evolve.

Naturally you separate API from implementation and have some way or another to discover/load the implementation for a given API. If your chosen infrastructure is worth telling your friends about, it supports multiple versions of any API and can dynamically start/stop/update the services that your subsystems use to collaborate with each other. The installed pieces form consistent class spaces with the same class possibly loaded multiple times in different versions and wired such that shared types are loaded from the same source. Any container environment that supports user defined plugins would have requirements similar to these. Take Eclipse, or a J2EE application server for example.

As my colleague Hal puts it

"OSGi is like toilet paper, sooner or later you are going to want to use it."

Capabilities and Requirements

An OSGi bundle is an ordinary jar with a couple of standard headers in its Manifest. Here I list a few important ones as a reference. The exhaustive set can be found in the OSGi Core Specification.

Bundle-SymbolicName: com.acme.daffy

The Bundle-SymbolicName header specifies a non-localizable name for this bundle. The bundle symbolic name together with a version must identify a unique bundle.

Bundle-Version: 1.1

The Bundle-Version header specifies the version of this bundle

Export-Package: org.osgi.util.tracker;version=1.3

The Export-Package header contains a declaration of exported packages.

Import-Package: org.osgi.util.tracker,org.osgi.service.io;version=1.4

The Import-Package header declares the imported packages for this bundle.

Require-Bundle: com.acme.chess

The Require-Bundle header specifies that all exported packages from another bundle must be imported, effectively requiring the public interface of another bundle.

In an abstract way, the bundle headers form a set of Capabilities that a bundle provides and another set of Requirements that a bundle has on the environment or other bundles. In most cases Requirements can be mandatory or optional and in some cases Requirements can be satisfied by Capabilities from the same bundle.

When the Framework makes a connection between a Requirement and a Capability it is said to have established a Wire. This happens at the RESOLVE phase of a bundle. The details of how an OSGi Framework works out the wires between the bundles is not our subject. Instead it is sufficient to know that every OSGi Framework implements this non-trivial, non-linear OSGi resolution algorithm in one way or another. Some Frameworks do this more successful than others and a distinguishing metric would be the success/error response time and ability to form consistent class spaces that include if not all but most of the installed bundles.

Why use a standalone Resolver

For most use cases the OSGi resolution algorithm is an implementation detail at the Framework level that you don't need to worry about. You install a few Bundles, start them or trigger a class load on an installed bundle and the Framework resolves the installed bundles transparently. Although there is an API method on the PackageAdmin to resolve bundles explicitly it is not what you would do normally.

The need for a resolver comes into the game when you want to do impact analysis or provide a smart repository. Impact analysis is when you have a running system and want to know if a set of bundles would resolve on that system without actually modifying the system. With a smart repository you can say, if have these requirements, give me the bundles that I need to install to provide the needed capabilities.

The Apache Felix Resolver

Every other month, when we both can make it, I meet Richard at the Enterprise Expert Group (EEG) meetings. Richard rewrote Felix resolver to work on the general notion of capabilities and requirements. This is part of felix-framework-3.0.1 and forms the foundation of what comes next.

Standalone Resolver Requirements

We had a number of requirements on an OSGi Resolver that I'd like to share with you here:

Independent of Core Framework implementation
Not bound to the Manifest as the meta data provider
Works on abstract notion of Module, Capability, Requirement, Wire
Explicit wiring for all mandatory requirements
Easy and intuitive user API
Extensible SPI for Resolver providers
Sensible default implementation stubs for Resolver providers
Callbacks for framework integration and resolved modules
Attachment support on various resolver atrifacts

Every framework parses/validates and caches the Manifest. So we did not want the resolver to do this again. Instead we provide a resolver meta data model that can be constructed in memory (i.e. mapped to from whatever the framework uses internally). Additionally, we provide an OSGi meta data model that can also be constructed in memory or from the Manifest.

In the JBoss Application Server we provide an OSGi view for non-OSGi deployments and the ability to access/inject OSGi services in other component models. For example CDI components can have OSGi services injected and vice versa. You will see this functionality in AS7. For that reason the resolver needs to work on the abstract notion of Module, Capability, Requirement which may come from non-OSGi deployments that nevertheless take part in OSGi resolution.

If a module is resolved, it is guaranteed that every mandatory Requirement has a Wire to a Capability.

Resolver clients can register callbacks to get informed when the Resolver changes the wiring for a Module.

The Resolver object model can have arbitrary state attached to it, which removes the need to map client state to resolver state and vice versa.

Working with the Resolver

The jbosgi-resolver project is hosted on GitHub together with all the other JBoss OSGi projects that we currently work on. When you use Maven, you can declare a dependency on the resolver like this:

<dependency>
  <groupId>org.jboss.osgi.resolver</groupId>
  <artifactId>jbosgi-resolver-api</artifactId>
  <version>1.0.0</version>
</dependency>
<dependency>
  <groupId>org.jboss.osgi.resolver</groupId>
  <artifactId>jbosgi-resolver-felix</artifactId>
  <version>3.0.1</version>
</dependency>

<repository>
  <id>jboss-public-repository-group</id>
  <name>JBoss Public Maven Repository Group</name>
  <url>https://repository.jboss.org/nexus/content/groups/public/</url>
  <layout>default</layout>
  <releases>
    <enabled>true</enabled>
    <updatePolicy>never</updatePolicy>
  </releases>
  <snapshots>
    <enabled>true</enabled>
    <updatePolicy>never</updatePolicy>
  </snapshots>
</repository>

Lets start by creating a Resolver instance and add a Module to it that has its Capabilities and Requirements populated from Manifest.

// Create a resolver instance
XResolver resolver = XResolverFactory.getResolver();

// Create the resolver module
XModuleBuilder builder = XResolverFactory.getModuleBuilder();
XModule module = builder.createModule(1, manifest);

// Add the module to the resolver
resolver.addModule(module);

Now you would create and add a few more modules until you actually trigger the resolve process

// Resolve the modules and report resolver errors
Set resolved = resolver.resolveAll(unresolved);
for (XModule resModule : unresolved)
{
   if (resModule.isResolved() == false)
   {
      Exception ex = resModule.getAttachment(XResolverException.class);
      log.error("Cannot resolve: " + resModule, ex);
   }
}

The resolver uses the above mentioned Attachement API to feed back the individual resolve exceptions. You can also register a ResolverCallback when you need to do locking or want to get informed about resolver progress.

A few changes were necessary to felix-framework-3.0.1 to abstract resolver dependencies on actual framework implementation. These can be picked up here.

May this be useful

JBossOSGi 1.0.0.Beta8 released

2010-06-28T16:57:00.004+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta8.

You can download the binary here: jboss-osgi-installer-1.0.0.Beta8.jar

The release comes with improvements in the following areas

Integrate Apache Felix resolver
Added support for DynamicImport-Package
Implementation of the StartLevel Service
Remove Felix and Equinox from the Installer (JBoss Framework reached acceptance threshold)

For details please have a look at the latest version of our User Guide.

Here are the change log details

Bug

[JBOSGI-151] - Cannot resolve circular dependencies
[JBOSGI-213] - Unexpected dependee state changes
[JBOSGI-317] - Context is already registered in domain DefaultDomain
[JBOSGI-318] - Linkage error for javax.servlet.Servlet in AS600
[JBOSGI-319] - LinkageError for the type javax/servlet/Servlet
[JBOSGI-323] - DynamicImport-Package takes presendence over embedded classes
[JBOSGI-324] - Cannot start EventAdmin service in AS
[JBOSGI-326] - MC service does not maintain properties
[JBOSGI-334] - Fix Start Level Support from the webconsole
[JBOSGI-338] - Cannot obtain EventAdmin service
[JBOSGI-341] - Endless loop at AS server startup
[JBOSGI-342] - Bundle resolution depends on install order
[JBOSGI-344] - When stopping the framework, bundles need to be taken down in reverse startlevel order
[JBOSGI-348] - EventAdmin unexpectedly unregistered in Runtime

Feature Request

[JBOSGI-138] - Proper system BundleContext implementation
[JBOSGI-143] - Add support for DynamicImport-Package
[JBOSGI-184] - Allow for overlay of jboss-osgi-bootstrap.xml
[JBOSGI-311] - Provide access to org.osgi.jmx API in OSGiFrameworkTest
[JBOSGI-320] - Integrate Apache Felix resolver
[JBOSGI-332] - Enhance the StartLevel plugin to support specification of start level
[JBOSGI-333] - Make it possible to specify the initial start level of the system

Task

[JBOSGI-94] - Remove DeploymentProvidedDeploymentUnitFilter
[JBOSGI-235] - Verify system classpath access
[JBOSGI-301] - Enable VFS3 leak detection in runtime
[JBOSGI-310] - Link generated javadoc to org.osgi API
[JBOSGI-314] - Change Hudson QA setup to work with Git
[JBOSGI-315] - Integrate jboss-osgi-http in distribution
[JBOSGI-316] - Verify integrity of the jboss-osgi-framework-all.jar
[JBOSGI-327] - Add support for JBossAS-6.0.0.M3
[JBOSGI-328] - Merge framework vfs30 support with core
[JBOSGI-335] - Ensure that start levels are supported via JMX
[JBOSGI-349] - Remove Felix and Equinox from the Installer
[JBOSGI-350] - Add OSGi Alliance trade mark to images in userguide
[JBOSGI-351] - Release jboss-osgi-1.0.0.Beta8
[JBOSGI-352] - Remove dependency on osgi deployers project
[JBOSGI-139] - Implement system BundleContext.loadClass()
[JBOSGI-278] - Revisit ControllerContext handling

Enjoy

JBossOSGi 1.0.0.Beta7 released

2010-04-15T14:30:00.005+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta7.

You can download the binary here: jboss-osgi-installer-1.0.0.Beta7.jar

The release comes with improvements in the following areas

Enterprise OSGi bundle management (JMX)
JSR160 compliant JMXConnector
Integrate JBoss OSGi with AS 6.0.0.M3
Framework service hooks
OSGi core TCK compliance 40%

For details please have a look at the latest version of our User Guide.

Here are the change log details

Bug

[JBOSGI-292] - PackageAdmin cannot obtain classloading metadata
[JBOSGI-295] - NullPointerException in ExportedPackageHelper constructor
[JBOSGI-297] - OSGiBootstrapBean spinning on System.in read
[JBOSGI-299] - WebConsole does not display on jbossas/trunk
[JBOSGI-300] - Felix integration breaks jbossas/trunk bootstrap

Feature Request

[JBOSGI-126] - Replace the SPI JMX functionality by RFC-139 API
[JBOSGI-307] - JSR160 compliant JMXConnector
[JBOSGI-267] - Allow multiple bundles to change state at once

Task

[JBOSGI-83] - Enterprise OSGi JMX
[JBOSGI-289] - Migrate all components to jboss-logging
[JBOSGI-290] - Use LifecycleInterceptor with Aries Blueprint
[JBOSGI-303] - Upgrade to equinox-3.5.2
[JBOSGI-304] - Upgrade to felix-2.0.4
[JBOSGI-302] - Add support for service hooks
[JBOSGI-312] - Integrate JBoss OSGi with AS 6.0.0.M3

Errata

Due to the recent migration of the JBoss Maven Repositories to Nexus, you might need to make adjustments to your ~/.m2/settings.xml

Enjoy

JBossOSGi 1.0.0.Beta6 Released

2010-02-08T16:26:00.004+01:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta6.

You can download the binary here: jboss-osgi-installer-1.0.0.Beta6.jar

The release comes with improvements in the following areas

Initial support for fragments.
Initial support for Bundle.update().
Initial support for native code libraries.
Support for R3 bundles.
Support for bundle header localization.
Improved Blueprint support, using Apache Aries Blueprint.

For details please have a look at the latest version of our User Guide.

Here are the change log details

Bug

[JBOSGI-210] - Bundle installed but not started with hot deploy
[JBOSGI-283] - WebApp extender not installed by default
[JBOSGI-145] - JAXB classes are loaded from the system classpath
[JBOSGI-204] - Failure in Bundle.start() uninstalls the bundle
[JBOSGI-286] - Investigate classloading of javax.* classes
[JBOSGI-287] - Optional import loaded from system classloader

Feature Request

[JBOSGI-269] - Add initial support for Bundle.update()
[JBOSGI-271] - Initial support for R3 bundles
[JBOSGI-272] - Implement bundle header localization
[JBOSGI-273] - Differenciate R3/R4 bundle validation
[JBOSGI-274] - Cache bundle header for default locale
[JBOSGI-275] - Add support for Bundle.update() from original location
[JBOSGI-276] - Add initial support for native code libraries
[JBOSGI-277] - Add initial bundle fragment support

Task

[JBOSGI-263] - Integrate Aries Blueprint implementation
[JBOSGI-265] - Update to jboss-osgi-framework-1.0.0.Alpha3
[JBOSGI-281] - Release JBoss OSGi 1.0.0.Beta6
[JBOSGI-264] - Update to jboss-kernel-2.2.x stable release
[JBOSGI-279] - Update to jboss-cl-2.2.x stable release
[JBOSGI-284] - Investigate version numbering scheme

Enjoy

ServiceLoader and how it relates to OSGi

2010-01-27T15:54:00.027+01:00

An important aspect of good software architecture is that clients of your components can interact with well defined and stable APIs. The concept of interfaces is an inherent part of the Java programming language and also central to the OSGi Service Layer.

Lets have a look at a simple service that I want to migrate from a plain Java programming model to OSGi.

public interface AccountService
{   
   /** Get the current balance */   
   long getBalance();   

   /** Credit the given amount and return the current balance */   
   long credit(long amount);   

   /** Withdraw the given amount and return the current balance */   
   long withdraw(long amount);
}

This interface would be part of the API jar (i.e. serviceloader-api.jar) that I package and distribute to the clients of my AccountService implementation. I have another jar that contains the implementation (i.e. serviceloader-impl.jar) and also a file in META-INF/services that names the implementation class

The implementation of my AccountService would be in a different package than the interface, for example something like '...serviceloader.service.internal'. Clients would be encouraged never to import anything from '*.internal'

A Java client could obtain an instance of the AccountService by using the well known ServiceLoader that is part of JDK1.6.

ServiceLoader loader = ServiceLoader.load(AccountService.class);
AccountService service = loader.iterator().next();

So far so good, but there are a number of issues with this approach. The most obvious one is that of the potential availability of more than one implementation of the same interface. The ServiceLoader uses the current thread's context class loader to discover all available service implementations. It then uses the same class loader to load the service instances.

The client gets presented with an iterator of available service implemenations, but what are the criteria does the client use to choose the specific implementation it really needs? We could add something like getVersion(), getVendor(), getSomeOtherProp() to our AccountService, which the client could then use to pick the implementation it needs, but this approach would pollute our AccountService with concerns that are not about accounting.

Another potential problem is that the client could directly instantiate or cast the service instance to gain access to internal functionality, which bypasses the fundamentals of abstraction and modularity that motivated us to use a service interface in the first place.

How does OSGi solve this problem?

In OSGi, a bundles can define the transitive closure of the API that it wants to make publicly available. In case of our API bundle the OSGi manifest could look like this

Bundle-ManifestVersion: 2
Bundle-SymbolicName: example-serviceloader-api
Export-Package: example.serviceloader.service;version="1.0"

Please note, that we associate a specific version with the package that contains the service interfaces. This is the version of our public contract. The package is versioned, not the API bundle. This allows us to rethink and change our packaging strategy in the future.

The bundle that contains the implementation could have a manifest like this

Bundle-ManifestVersion: 2
Bundle-SymbolicName: example-serviceloader-impl
Bundle-Vendor: JBoss, a division of RedHat
Bundle-Version: 1.0.0
Import-Package: example.serviceloader.service;version="[1.0,1.1)"
Private-Package: example.serviceloader.service.internal

The implementation explicitly states that it is valid for API version greater and equal to 1.0 up until but not including 1.1. Please also note, that the '*.internal' package is declared private, which prevents any other bundle from seeing the contents of that package even though the individual classes may be public. A client running in an OSGi environment cannot instantiate the implementation directly, nor can it cast to it.

The implementation bundle could register the AccountService with the framework in BundleActivator.start() like this

Hashtable props = new Hashtable();
props.put("service.vendor", "JBoss, a division of RedHat");
AccountService service = new AccountServiceImpl();
context.registerService(AccountService.class.getName(), service, props);

Please note, that we associate some meta data with the service registration. In this case the service vendor, which could be used by a client to obtain a specific vendor implementation.

The client bundle could statically obtain a service instance like this

String filter = "(service.vendor=JBoss*)";
String sname = AccountService.class.getName();
ServiceReference[] srefs = context.getServiceReferences(sname, filter);
AccountService service = (AccountService)context.getService(srefs[0]);

Please note that the client explicitly defines a filter criteria for available services. In this case the specific service vendor.

To account for the dynamic nature of OSGi services, the client would not want to make the assumption that the AccountService is already available when its BundleActivator.start() method is invoked by the framework. This assumption would create an implicit start order dependency of the implementation and client bundle (i.e. the implementationbundle must be started before the client bundle).

If the the client can dynamically react to the AccountService coming and going it should use code like this

String sname = AccountService.class.getName();
String filterstr = "(&(objectClass=" + sname + ")(service.vendor=JBoss*))";
Filter filter = FrameworkUtil.createFilter(filterstr);

// Track the service
ServiceTracker tracker = new ServiceTracker(context, filter, null)
{   
   public Object addingService(ServiceReference reference)   
   {
      service = (AccountService)super.addingService(reference);
      return service;
   }

   public void removedService(ServiceReference reference, Object tracked)
   {
      super.removedService(reference, tracked);
      service = null;
   }
};
tracker.open();

The dynamic nature of OSGi services is in fact its real beauty. The client gets informed when the service gets modified (i.e. a new version of the service from the same vendor becomes available)

Auto registration of META-INF/services

David Bosschaert, a friend and colleague recently brought the topic of META-INF/services and its prevalent nature in Java component architecture to my attention. Because it is such a common pattern, I investigated how an OSGi framework could reuse the information that is already present in META-INF/services when a non OSGi component library is wrapped or migrated to be used in an OSGi framework.

Starting with JBoss OSGi 1.0.0.Beta6, which should come out early Feb-2010, we provide a jboss-osgi-serviceloader bundle. That registers a LifecycleInterceptor to introspect every installed bundle. Should a bundle contain META-INF/services, these services are automatically registered as ServiceFactories.

The interceptor associates the following properties with every service it registers

Have a look at the service loader example that demonstrates this functionality

Running org.jboss.test.osgi.example.serviceloader.ServiceLoaderTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.415 sec

Conclusion

The OSGi service model has much to offer over the traditional Java model of interfaces and service factories. The ServiceLoader being a particular and well known implementation of the more general service factory pattern.

In OSGi you can have multiple implementations of the same service available in the framework. Services can be associated with arbitrary meta data, which means you can version your public contract. Clients can use a meta data filter to select a particular implementation. Implementation, can be strictly separated from API with no back doors left open.

Lastly a few items from my OSGi best practises catalogue

Export the public contract, not the implementation
Declare implementation details in Private-Package
Associate specific versions with your public API packages
Define dependencies on package versions, not bundle versions
Define which version range of the API a you implement
Separate the API bundle from the implementation bundle
Keep you public contract concise, well documented and simple
Components should interact with services, not arbitrary stuff you export
Only service interfaces and their associated types should be exported
Track services dynamically, instead of getting the service from the framework

May this be useful

JBossOSGi 1.0.0.Beta5 Released

2009-12-09T10:21:00.002+01:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta5.

You can download the binary here: jboss-osgi-installer-1.0.0.Beta5.jar

The release comes with improvements in the following areas

Improved JBoss Microcontainer based Framework support.
Improved Eclipse Equinox Integration support.
Added Enterprise OSGi Transaction support.
Added Compendium Event Admin support.
Added JBossXB based XML Binding support.
Added Lifecycle Interceptor support.

For details please have a look at the latest version of our User Guide.

Here are the change log details

Bug

[JBOSGI-129] - Filter behaviour change in r4v42
[JBOSGI-137] - Cannot parse Bundle-SymbolicName
[JBOSGI-153] - Cannot parse Import-Package parameters
[JBOSGI-187] - Husky SocketInvocation may block forever
[JBOSGI-199] - Use thread safe collections where information is mutable
[JBOSGI-212] - Cannot refresh Microcontainer service

Feature Request

[JBOSGI-125] - Add ManagedFramework service
[JBOSGI-202] - Allow override of where the bootstrap file comes from

Task

[JBOSGI-157] - JTA (RFC-98) - Initial Implementation
[JBOSGI-181] - Add EventAdmin as available service
[JBOSGI-182] - Release JBoss OSGi 1.0.0.Beta5
[JBOSGI-183] - Introduce notion of OSGi Interceptors
[JBOSGI-188] - Separate DeployerService from SPI
[JBOSGI-190] - Allign getting started guide with latest release
[JBOSGI-200] - Split getParameter(s) calls into directives/attributes
[JBOSGI-215] - Update Blueprint to 1.0.0.Alpha3
[JBOSGI-216] - Update to Apache Felix-2.0.2
[JBOSGI-217] - Update to Eclipse Equinox-3.5.1
[JBOSGI-218] - Update to jboss-osgi-common-1.0.3
[JBOSGI-219] - Update to jboss-osgi-husky-1.0.2
[JBOSGI-220] - Update to jboss-osgi-jmx-1.0.2
[JBOSGI-221] - Update to jboss-osgi-jndi-1.0.2
[JBOSGI-222] - Update to jboss-osgi-microcontainer-2.0.9
[JBOSGI-223] - Update to jboss-osgi-spi-1.0.3
[JBOSGI-224] - Update to jboss-osgi-xml-binding-2.0.2.Beta3
[JBOSGI-225] - Update to jboss-osgi-apache-xerces-2.9.1.SP3
[JBOSGI-226] - Update to jboss-osgi-hotdeploy-1.0.3
[JBOSGI-227] - Update to jboss-osgi-framework-1.0.0.Alpha2
[JBOSGI-228] - Update to jboss-osgi-jaxb-2.1.10.SP3
[JBOSGI-229] - Add jboss-osgi-deployment-1.0.0
[JBOSGI-230] - Add jboss-osgi-jta-1.0.0
[JBOSGI-231] - Add jboss-osgi-reflect-2.0.2
[JBOSGI-232] - Add jboss-osgi-webapp-0.7.2
[JBOSGI-233] - Update to org.apache.felix.configadmin-1.2.4
[JBOSGI-234] - Add org.apache.felix.eventadmin-1.0.0

Enjoy

OSGi Framework Launch

2009-11-03T16:50:00.013+01:00

In this post I am going to look at the problems involved when you need to launch an OSGi Framework independent of the actual Framework implementation. There will be coverage of

Framework Launch API
OSGi Bootstrap abstraction

The Framework Launch API

Starting with Version 1.5 of the Framework API, which is part of the core r4v42 specification, OSGi comes with the ability to launch an OSGi Framework in an implementation agnostic manner. For this, clients interact with the classes in package org.osgi.framework.launch like this

// Load the framework factory
FrameworkFactory factory = loadFrameworkFactory();

// Load the framework configuration
Map config = loadFrameworkConfig();

// Create a new instance of the framework
Framework framework = factory.newFramework(config);
try
{
   // Start the framework
   framework.start();

   // do stuff
}
finally
{
   // Stop the framework
   framework.stop();

   // Wait for the framework to stop completely
   framework.waitForStop(3000);
}

As you can see, this API is fairly low level. The client provides code that loads the FrameworkFactory, as well as code that obtains the Framework configuration somehow. At this level, there is no API or standard config that defines initial bundle provisioning.

OSGi Bootstrap abstraction

If you are running on JDK-1.6 there is a ServiceLoader available that can be used to load the FrameworkFactory like this

// Load the framwork factory
ServiceLoader loader = ServiceLoader.load(FrameworkFactory.class);
FrameworkFactory factory = loader.iterator().next();

// Create a new instance of the framework
Framework framework = factory.newFramework(null);

Since this API might not be available in every environment, JBoss OSGi also provides a ServiceLoader as part of its Service Provider Interface (SPI). Conceptually very similar, here is how you would use this API

// Load the framework factoryFramework
Factory factory = ServiceLoader.load(FrameworkFactory.class);

// Create a new instance of the framework
Framework framework = factory.newFramework(null);

Both variants of the service loader provide you with an instance of FrameworkFactory from which you can now use to create a new Framework instance. The null parameter causes the Framework to use it's default configuration.

The JBoss OSGi SPI supports a Framework bootstrap process based on unified configuration files. In its most simple form the usage of this API would look like this

// Get the configured bootstrap provider
OSGiBootstrapProvider bootProvider = OSGiBootstrap.getBootstrapProvider();

// Get the configured framework from the boot provider
Framework framework = bootProvider.getFramework();

An OSGiBootstrapProvider is an abstraction of a provider that can somehow bootstrap an OSGi Framework. A concrete implementation and also the default that is used if no other provider is configured is the PropertiesBootstrapProvider. As the name suggests, this bootstrap provider can be configured using a plain java properties file. The default location of this file is a resource called jboss-osgi-framework.properties loadable from the bootstrap classpath.

An example of such a properties file is shown below

# Extra server specific properties
org.jboss.osgi.spi.framework.extra=${somedir}/osgi-extra.properties

# Properties to configure the Framework
org.osgi.framework.storage=${osgi.server.home}/data/osgi-store
org.osgi.framework.storage.clean=onFirstInit

# Hot Deployement
org.jboss.osgi.hotdeploy.scandir=${osgi.server.home}/deploy

# Bundles that need to be installed with the Framework automatically
org.jboss.osgi.spi.framework.autoInstall=\
file://${osgi.home}/server/minimal/deploy/org.osgi.compendium.jar

# Bundles that need to be started automatically 
org.jboss.osgi.spi.framework.autoStart=\
file://${osgi.home}/server/minimal/deploy/org.apache.felix.log.jar \
file://${osgi.home}/server/minimal/deploy/jboss-osgi-common.jar \
file://${osgi.home}/server/minimal/deploy/jboss-osgi-hotdeploy.jar

Noteworthy, are perhaps the properties that can be used for initial framework provisioning

and the extension point that allows to recursively split the properties over multiple files

org.jboss.osgi.spi.framework.extra

All other properties are simply passed on the FrameworkFactory.newFramework(Map config) method.

We looked at the basic OSGi Framework launch API and have seen how to externalize Framework configuration to property files. Other bootstrap providers could work of your favourite XML dialect. For the Apache Felix JBossAS integration we use a jboss-beans.xml configuration.

With my next post I am going to start a series of Enterprise OSGi topics. There should be coverage of JTA, JMX, JNDI, WebApp and perhaps others.

May this be useful

Extender Pattern vs. Lifecycle Interceptor

2009-10-23T19:24:00.025+02:00

With this post I'd like to give a little more background on the well known OSGi Extender Pattern, when this pattern is applicable and what might be an alternative when it is not applicable. There will be coverage of

Basics of extending an OSGi Bundle
Advantages and drawbacks of Extenders
Notion of "self ordering" LifecycleInterceptor

Extending an OSGi Bundle

The basic functional sequence of an OSGi Extender goes like this

Extender registers itself as BundleListener
Bundle gets installed/started
Framework fires a BundleEvent
Extender picks up the BundleEvent (e.g. STARTING)
Extender reads metadata from the Bundle and does its work

There is no extender specific API. It is a pattern rather than a piece of functionality provided by the Framework. Typical examples of extenders are the Blueprint or Web Application Extender.

The following illustration shows how a WAR Extender might process an OSGi Web Application to register servlets that are declared in WEB-INF/web.xml with the OSGi HttpService.

Client code that installs, starts and uses the registered endpoint could look like this

// Install and start the Web Application bundle
Bundle bundle = context.installBundle("mywebapp.war");
bundle.start();

// Access the Web Application
String response = getHttpResponse("http://localhost:8090/mywebapp/foo");
assertEquals("ok", response);

This seemingly trivial code snippet has a number of issues that are probably worth looking into in more detail

The WAR might have missing or invalid web metadata (i.e. an invalid WEB-INF/web.xml descriptor)
The WAR Extender might not be present in the system
There might be multiple WAR Extenders present in the system
Code assumes that the endpoint is available on return of bundle.start()

It should be noted that the Extender, which is essentially a synchronous or asynchronous BundleListener has no way to veto the install or start transition of the bundle. Even if the Extender cannot process the metadata or fails for some other reason, the bundle will start just the same. Client code would see an ACTIVE bundle, which in fact might not be active at all in the colloquial sense of the word.

Most Blueprint or WebApp bundles are not useful if their Blueprint/Web metadata is not processed. Even if they are processed but in the "wrong" order a user might see unexpected results (i.e. the webapp processes the first request before the underlying Blueprint app is wired together).

As a consequence I would say that the extender pattern is useful in some cases but not all. IMHO it is mainly useful if a bundle can optionally be extended in the true sense of the word.

There is an RFP in the works that addresses many of the above issues. Adrian Colyer from SpringSource has initiated the work around RFP-118 Multiple Extenders in Nov-2008. The document is currently in the non-public review phase of the OSGi Alliance Enterprise Expert Group. (EEG)

Intercepting the Bundle Lifecycle

If the use case requires the notion of "interceptor" the extender pattern is less useful. The use case might be such that you would want to intercept the bundle lifecycle at various phases to do mandatory metadata processing.

An interceptor could be used for annotation processing, byte code weaving, and other non-optional/optional metadata processing steps. Traditionally interceptors have a relative order, can communicate with each other, veto progress, etc.

Lets look at how multiple interceptors can be used to create Web metadata and publish endpoints on the HttpService based on that metadata.

Here is how it works

The Wep Application processor registers two LifecycleInterceptors with the LifecycleInterceptorService
The Parser interceptor declares no required input and WebApp metadata as produced output
The Publisher interceptor declares WebApp metadata as required input
The LifecycleInterceptorService reorders all registered interceptors according to their input/output requirements and relative order
The WAR Bundle gets installed and started
The Framework calls the LifecycleInterceptorService prior to the actual state change
The LifecycleInterceptorService calls each interceptor in the chain
The Parser interceptor processes WEB-INF/web.xml in the invoke(int state, InvocationContext context) method and attaches WebApp metadata to the InvocationContext
The Publisher interceptor is only called when the InvocationContext has WebApp metadata attached. If so, it publishes the endpoint from the WebApp metadata
If no interceptor throws an Exception the Framework changes the Bundle state and fires the BundleEvent.

Client code is identical to above.

// Install and start the Web Application bundle
Bundle bundle = context.installBundle("mywebapp.war");
bundle.start();

// Access the Web Application
String response = getHttpResponse("http://localhost:8090/mywebapp/foo");
assertEquals("ok", response);

The behaviour of that code however, is not only different but also provides a more natural user experience.

Bundle.start() fails if WEB-INF/web.xml is invalid
An interceptor could fail if web.xml is not present
The Publisher interceptor could fail if the HttpService is not present
Multiple Parser interceptors would work mutually exclusiv on the presents of attached WebApp metadata
The endpoint is guaranteed to be available when Bundle.start() returns

The general idea is that each interceptor takes care of a particular aspect of processing during state changes. In the example above WebApp metadata might get provided by an interceptor that scans annotations or by another one that generates the metadata in memory. The Publisher interceptor would not know nor care who attached the WebApp metadata object, its task is to consume the WebApp metadata and publish endpoints from it.

The current BundleContext API does not allow for arbitrary attachments as contextual information to be passed between interceptors. The InvocationContext adds that plus the notion of a VirtualFile that represents the Bundle's content. The VirtualFile is necessary to access arbitrarily deeply nested resources regardless of their actual location.

Here a sneak preview of the ParserInterceptor that will come as part of the Interceptor example in JBoss OSGi 1.0.0.Beta5

public void invoke(int state, InvocationContext context)
{
  // Do nothing if the metadata is already available  
  HttpMetadata metadata = context.getAttachment(HttpMetadata.class);
  if (metadata != null)
    return;

  // Parse and create metadta on STARTING
  if (state == Bundle.STARTING)
  {
    try
    {
      VirtualFile root = context.getRoot();
      VirtualFile propsFile = root.getChild("/metadata.properties");
      if (propsFile != null)
      {
        log.info("Create and attach HttpMetadata");
        metadata = createHttpMetadata(propsFile);
        context.addAttachment(HttpMetadata.class, metadata);
      }
    }
    catch (IOException ex)
    {
      throw new LifecycleInterceptorException(ex);
    }
  }
}

and here the associate PublisherInterceptor

public void invoke(int state, InvocationContext context)
{
  // HttpMetadata is guaratied to be available because we registered
  // this type as required input
  HttpMetadata metadata = context.getAttachment(HttpMetadata.class);

  // Register HttpMetadata on STARTING 
  if (state == Bundle.STARTING)
  {
    String servletName = metadata.getServletName();
    try
    {
      log.info("Publish HttpMetadata: " + metadata);

      // Load the endpoint servlet from the bundle
      Bundle bundle = context.getBundle();
      Class servletClass = bundle.loadClass(servletName);
      HttpServlet servlet = (HttpServlet)servletClass.newInstance();

      // Register the servlet with the HttpService
      HttpService httpService = getHttpService(context, true);
      httpService.registerServlet("/servlet", servlet, null, null);
    }
    catch (RuntimeException rte)
    {
      throw rte;
    }
    catch (Exception ex)
    {
      throw new LifecycleInterceptorException(ex);
    }
  }

  // Unregister the endpoint on STOPPING 
  else if (state == Bundle.STOPPING)
  {
    log.info("Unpublish HttpMetadata: " + metadata);
    HttpService httpService = getHttpService(context, false);
    if (httpService != null)
      httpService.unregister("/servlet");
  }
}

This post and the initial implementation that is based on these concepts is a follow up of a discussion that I had with Hal Hildebrand from Oracle at one of our recent OSGi EEG meetings. Please stay tuned to find out in what shape or form these ideas develop.

In parallel to the standards efforts you will of course get this functionality as part of the next JBoss OSGi release, which should come out 01-Dec-2009.

That's it for now. In my next post I will explore the Framework launch API in more detail and show how you can bootstrap an OSGi Framework independent of the actual Framework implementation.

May this be useful.

JBossOSGi 1.0.0.Beta4 Released

2009-10-14T19:07:00.003+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta4.

You can download the binary here: jboss-osgi-installer-1.0.0.Beta4.jar

The release comes with improvements in the following areas

Initial release of our native JBossMC based OSGi Framework.
Added support for OSGi WebApps using WebApp Extender
Improved support for the HttpService.

For details please have a look at the latest version of our User Guide.

Here are the change log details

Feature Request

[JBOSGI-110] - Support WAR deployments in the OSGi runtime
[JBOSGI-127] - Provide build and hudson support for MC facade
[JBOSGI-128] - Add Framework launch API

Task

[JBOSGI-80] - Add support for Framework Launching (RFC-132)
[JBOSGI-132] - Release JBoss MC Framework 1.0.0.Alpha1
[JBOSGI-134] - Add support for BundleContext.getDataFile()
[JBOSGI-142] - Investigate classloading space
[JBOSGI-148] - Autostart bundles when deployed in JBossAS
[JBOSGI-156] - Setup r4v42 core TCK
[JBOSGI-159] - Fire events asynchronously
[JBOSGI-160] - Use Pax Web instead of Apache Http-Service
[JBOSGI-164] - Update Blueprint to 1.0.0.Alpha2
[JBOSGI-165] - Update to jboss-osgi-common-1.0.2
[JBOSGI-166] - Update to jboss-osgi-common-core-2.2.13.GA
[JBOSGI-167] - Update to jboss-osgi-husky-1.0.1
[JBOSGI-168] - Update to jboss-osgi-jmx-1.0.1
[JBOSGI-169] - Update to jboss-osgi-jndi-1.0.1
[JBOSGI-170] - Update to jboss-osgi-microcontainer-1.0.2
[JBOSGI-171] - Update to Eclipse Equinox-3.5
[JBOSGI-172] - Update to Apache Felix-2.0.0
[JBOSGI-173] - Update to jboss-osgi-spi-1.0.2
[JBOSGI-174] - Update to jboss-osgi-webconsole-1.0.1
[JBOSGI-175] - Update to osgi core/compendium R4v42
[JBOSGI-176] - Release JBoss OSGi 1.0.0.Beta4
[JBOSGI-133] - Pass all example tests with MC Framework

Bug

[JBOSGI-78] - ResourceNotFoundException too verbose
[JBOSGI-130] - Bundle is still in state INSTALLED after bundle.start()
[JBOSGI-135] - Cannot handle package being imported and exported by the same bundle
[JBOSGI-136] - Cannot resolve dependency against unstarted bundle
[JBOSGI-140] - Invalid delivery of framework events
[JBOSGI-144] - Framework does not handle ServiceFactory provided services properly
[JBOSGI-151] - Cannot resolve circular dependencies
[JBOSGI-155] - OutOfMemoryError on repeated install/unstall bundle
[JBOSGI-158] - Framework itself must be a bundle
[JBOSGI-161] - Cannot use commons-logging
[JBOSGI-162] - Cannot load classes from Bundle-ClassPath
[JBOSGI-163] - Husky invocation before async extender processing

Enjoy

OSGi Unit Testing

2009-10-14T15:32:00.012+02:00

With this post I'd like to give a little more background on OSGi unit testing. There will be coverage of

Basic problem of OSGi bundle testing
Running a unit test inside an OSGi Framework
Interaction between a test runner and the OSGi Framework

Introduction

One of the main characteristics of an OSGi environment is its high dynamicity. Services come and go at any time or get updated by newer versions. To verify that functionality provided by an OSGi Bundle does indeed behave as expected, you need good test coverage of that functionality. This of course is a general truth that is not limited to OSGi alone.

The benefit of unit testing is to isolate functionality and show that it behaves as expected. A unit test provides a strict, written contract that the piece of code must satisfy.

The basic problem in OSGi is that you cannot access the artefacts that you deploy in a bundle directly from the test case that runs external to the OSGi Framework. The test case is loaded from different classloader than the artefacts contained in the bundle.

Embedded OSGi Framework

This is probably the most common usage. A test or a wrapper around a collection of tests bootstraps the OSGi Framework installs a number of bundles and verifies their correct behaviour. Husky test cases leverage the OSGi Framework Launch API. Framework launching should not require prior knowledge of the actual framework implementation. OSGi Framework and test runner share the same VM. From the perspective of the test runner, the test can be executed like an ordinary unit test, which gives the developer the freedom of choice with respect to the runner (i.e. Eclipse, IntelliJ, Maven, Ant). The test reports results back to the runner like an ordinary unit test, which preserves the runner's test report functionality.

Remote OSGi Framework

In an enterprise scenario the OSGi Framework is more often than not a standalone container. The same test as above should be deployable in a remote framework that is already running. It is a configuration option of the test environment of whether the test gets installed into an embedded OSGi Framework or deployed to a remote framework instance. OSGi Framework and test runner do not share the same VM. From the perspective of the test runner, the test can still be executed like an ordinary unit test and it is completely transparent that the test gets actually executed in a remote environment. Conceptually, this is similar to what Apache Cactus is about.

Requirements

The solution MUST support plain JUnit4 POJO test cases
There SHOULD be no requirement to extend a specific test base class
There MUST be no requirement on a specific test runner
There SHOULD be a minimum test framework leakage into the test case
The test framework MUST support embedded and remote OSGi Runtimes with no change required to the test
The same test case MUST be executable from outside as well as from within the OSGi Framework
There SHOULD be a pluggable communication layer from the test runner to the OSGi Framework
The test framework MUST NOT depend on OSGi Framework specific features
There MUST be no automated creation of test bundles required by the test framework

Architecture

JBoss OSGi Husky has client side interceptor that fields the test request to an embedded/remote OSGi Framework where the test case is then actually executed.

How does it work

A Bridge intercepts a test and determines the FQN of the test case and the test method from the call stack. It then delegates the execution to the same (or another) test in and isolated test environment. An isolated test environment is one that does not have the same class loading space as the test itself.
A Bridge is associated with an Invoker. Invokers may be arbitarily complex. Local 'in proccess' invokers are possible just as well as remote invokers.
The Invoker sends the Request to a Connector in the isolated test environment.
A Connector has associated PackageListeners that are responsible for processing test cases for their respective test packages.
A PackageListeners delegates the Request to a test Runner, typicaly this would be a JUnitRunner.
The Runner injects the Context into the test case and returns a Response, which the Connector returns to the Invoker.
The Bridge finally translates potential Failures that may be contained in the Result, to test failures on the client side.

The JBoss OSGi jboss-osgi-husky.jar bundle registers the Connectors. The JMXConnector is always registered. The SocketConnector is registered when the appropriate configuration options are set. It then registers the HuskyExtender, which is a BundleListener that inspects every incomming bundle for the Test-Package manifest header. The Extender creates a PackageListener for every package in the 'Test-Package' manifest header and registers them with the available Connectors.

Configuration

In the target OSGi Framework, which is the one that has the jboss-osgi-husky.jar bundle installed, you set these properties.

# Husky socket connector properties
org.jboss.osgi.husky.runtime.connector.host=localhost
org.jboss.osgi.husky.runtime.connector.port=5401

Both properties must be set for the SocketConnector to be available.

On the client side, you configure the Invoker that you want to use.

# Husky invoker properties
org.jboss.osgi.husky.invoker=org.jboss.osgi.husky.internal.OSGiInvoker

This particular invoker will also look for the host and port properties and if availbale will use socket invocation.

Writing Husky Tests

In a typical Husky test you have

A discriminator to distinguish between client and 'in container' execution
An interceptor that delegates the call to an Invoker

For OSGi, the "discriminator" would be the BundleContext that gets injected by the 'in container' test Runner. The "interceptor" would be a call to one of the Bridge.run() variants.

public class SimpleHuskyTestCase
{
@ProvideContext
public BundleContext context;

...

@Test
public void testSimpleBundle() throws Exception
{
  // Tell Husky to run this test method within the OSGi Runtime
  if (context == null)
     BridgeFactory.getBridge().run();
  

  // Stop here if the context is not injected
  assumeNotNull(context);

  // Get the SimpleService reference
  ServiceReference sref = context.getServiceReference("SimpleService");
  assertNotNull("SimpleService Not Null", sref);

  // Access the SimpleService
  SimpleService service = (SimpleService)context.getService(sref);
  assertEquals("hello", service.echo("hello"));
}
}

The bundle that contains the test case must have the Test-Package manifest header configured.

Bundle-SymbolicName: example-simple-husky

# Export the package that contains the test case
Export-Package: org.jboss.test.osgi.example.simple

# Tell Husky that there are test cases in this package
Test-Package: org.jboss.test.osgi.example.simple

That's it for now. JBoss OSGi 1.0.0.Beta4 is ready and waiting for the files to show up on Sourceforge. In a follow up post you can read about our new native OSGi Framework implementation that is based on the JBoss Microcontainer and how JBoss OSGi uses Pax Web to provide support for OSGi WebApps.

May this be useful

JBossOSGi 1.0.0.Beta3 Released

2009-07-24T09:13:00.002+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta3.

You can download it here: jboss-osgi-installer-1.0.0.Beta3.ja

The release comes with improvements in the following areas

Early preview of the Blueprint Container Service with associated Blueprint Example.
More samples for SAX/DOM and JAXB processing.
Aggregated online API docs

For details please have a look at the latest version of our User Guide.

Here are the change log details

Feature Requests

[JBOSGI-93] - Uninstall bundles on OSGiRuntime.shutdown()
[JBOSGI-98] - Support configuration per profile
[JBOSGI-102] - Add support for static Husky context injection

Tasks

[JBOSGI-71] - Upgrade to IzPack 4.3.1
[JBOSGI-73] - Provide Blueprint example
[JBOSGI-95] - Provide JAXB example
[JBOSGI-97] - Provide SAX/DOM parser example
[JBOSGI-101] - Create a ziped source distribution
[JBOSGI-103] - Add support for BlueprintContainer API
[JBOSGI-104] - Upgrade to Felix Web Console 1.2.10
[JBOSGI-108] - Investigate statics on PackageAdmin.refresh
[JBOSGI-109] - Upgrade to Felix-1.8.1
[JBOSGI-111] - Allign distributed sources with libs
[JBOSGI-112] - Investigate Exception in SynchronousBundleListener

Bugs

[JBOSGI-66] - Support bundle deployment through web console
[JBOSGI-92] - Class.forName issue with XMLParserActivator
[JBOSGI-99] - No explicit control over bundle.start()
[JBOSGI-107] - MC beans cannot be redeployed after refresh

Enjoy

JBoss OSGi Runtime & JBossAS Integration

2009-06-05T14:10:00.039+02:00

Now that JBoss OSGi 1.0.0.Beta2 is out I thought I'll explain a little more in detail what the various JBoss OSGi runtime models are about. In this post I'll cover

JBoss OSGi integration in JBossAS
The standalone JBoss OSGi Runtime
The possible future of both

JBossAS has always been good at integrating loosely coupled services. In the 3.x and 4.x series that was done via a JMX based kernel in the 5.x series the AS switched to a Microcontainer based kernel. For JBoss OSGi only the 5.x series is relevenant so lets start with that.

Integration in JBossAS-5.x

Like any other service JBoss OSGi is integrated via a *-beans.xml descriptor.

More specifically, when you choose JBossAS integration in the Installer you will find and 'osgi.deployer' directory together with all your other MC deployers.

Deployers must be loaded first because as their name nicely suggests they deploy other services and applications. There is a lot to say about deployers, but lets focus on the JBoss OSGi specific osgi-deployers-jboss-beans.xml beans descriptor. Here you'll find all OSGi relevevant configuration options. For this post I'll take the Apache Felix integration as an example. There is however a similar beans descriptor for Equinox and Knopflerfish.

Without going in too much detail there are various beans configurations

OSGi Framework Integration
Bundle Management (JMX) Service
MC Integration Service
OSGi Deployers

Every time you deploy a bundle (i.e. drop it into the 'deploy' folder), the bundle gets processed by the OSGi Deployers, each of them taking care of a specific deployment aspect.

The JBoss OSGi AS integration looks something like this

You will notice that all the interesting AS provided services are 'outside' the OSGi world. You can think of them as 'system services' like the ones provided by the JVM itself. Hence a bundle wanting to access EJB, JTA, JPA, etc. can only do so if the packages that it imports are defined on the OSGi System Classpath. This would be the content of the 'org.osgi.framework.system.packages' property, which for Felix is currently defined like this


<key>org.osgi.framework.system.packages.extra</key>
<value>

<!-- system -->
org.apache.xerces.dom,

<!-- jboss-osgi -->
org.jboss.osgi.spi;version=1.0,
org.jboss.osgi.spi.capability;version=1.0,
org.jboss.osgi.spi.logging;version=1.0,
org.jboss.osgi.spi.management;version=1.0,
org.jboss.osgi.spi.service;version=1.0,
org.jboss.osgi.spi.testing;version=1.0,

<!-- jboss -->
org.jboss.logging,
org.jboss.virtual,
org.jboss.virtual.plugins.registry,
org.jboss.virtual.plugins.context.jar,
org.jboss.virtual.plugins.vfs.helpers,
org.jboss.virtual.protocol,
org.jboss.xb.binding;version=2.0,
org.jboss.xb.binding.sunday.unmarshalling;version=2.0,
</value>

Say good bye to modularity, if packages from services need to be defined statically as part of some non-recyclable deployer.

So how can the AS integration still be useful?

It is useful for folks who have plain OSGi applications that either do not interact with system services or can have static dependency on those services. i.e. you can send/receive JMS messages, but there cannot be more than one JMS service available nor can the JMS service come and go.
It is a neccessary starting point from which OSGi/AS integration can develop. What I describe here is the state of the current AS integration, over the course of time you should see posts explaining an ever improving OSGi/AS integration.

The AS intgration is available for

JBoss-5.0.1.GA
JBoss-5.1.0.GA
JBoss-5.2.0 (not yet released)
JBoss-6.0.0 (not yet released)

both for jdk1.5 and jdk1.6. Here is the full matrix.

There is another JBoss OSGi Runtime available, which is already covered to some extend in the Userguide. Lets have a closer look.

Standalone JBoss OSGi Runtime

The JBoss OSGi Runtime is a pure OSGi container onto which components, services and applications can be deployed.

Instead of bootstrapping the OSGi Framework from the Microcontainer, the Microcontainer Service is installed in the OSGi Framework as a bundle.

Preconfigured profiles, contain OSGi bundles that logically work together. A profile can be bootstrapped either as a standalone server or embedded in some other environment. With a startup time of less than 600ms, the runtime can be easily be bootstrapped from within plain JUnit4 test cases.

For a more detailed description and the feature set, please have a look at the userguide.

For this post lets focus on the '-c all' profile

[tdiesler@tdvaio runtime]$ bin/run.sh -c all
=========================================================================
JBossOSGi Bootstrap Environment
OSGI_HOME: /home/tdiesler/jboss-osgi-1.0.0.Beta2/runtime
JAVA: /usr/java/jdk1.6/bin/java
JAVA_OPTS: -Dprogram.name=run.sh ...
=========================================================================
... [FelixIntegration] OSGi Integration Felix - 1.0.0.Beta2
... [FelixIntegration] Installed bundle [1]: org.osgi.compendium
... [FelixIntegration] Installed bundle [2]: org.apache.felix.log
... [FelixIntegration] Installed bundle [3]: jboss-osgi-common
... [FelixIntegration] Installed bundle [4]: jboss-osgi-hotdeploy
... [OSGiBootstrap] JBossOSGi Runtime booted in 0.421sec
... [jboss-osgi-common] Installed: jboss-osgi-xml-binding [5]
... [jboss-osgi-common] Installed: jboss-osgi-microcontainer [6]
... [jboss-osgi-common] Installed: org.apache.felix.metatype [7]
... [jboss-osgi-common] Installed: jboss-osgi-jndi [8]
... [jboss-osgi-common] Installed: org.apache.felix.http.jetty [9]
... [jboss-osgi-common] Installed: org.apache.felix.configadmin [10]
... [jboss-osgi-common] Installed: jboss-osgi-jmx [11]
... [jboss-osgi-common] Installed: jboss-osgi-jaxb [12]
... [jboss-osgi-common] Installed: jboss-osgi-common-core [13]
... [jboss-osgi-common] Installed: jboss-osgi-webconsole [14]
... [jboss-osgi-common] Installed: jboss-osgi-apache-xerces [15]
... [jboss-osgi-jndi] JNDI started: JNP=localhost:1099
... [jboss-osgi-jmx] Bound to: jmx/invoker/RMIAdaptor
... [OSGiBootstrap] JBossOSGi Runtime started in 5.156sec

The OSGi Framework boots up and starts the services that are shown in the picture above. Although the startup time is considerably faster that that of the AS it should be mentioned that this is currently not optimized. OSGi comes with a lazy bundle activation policy. What you see above is 'eager' bundle activation for all. Lazy bundle activation means that bundles and their associated service can be started on demand, which should bring the startup time much closer to the boot time.

So why is this OSGi runtime useful?

It is useful for folks who want a "clean" OSGi environment with all the benefits that are described in the feature set
3rd party bundles can be installed in that runtime and provide truly modular services similar to the ones that exist in the AS integration.
It is the foundation of our OSGi activities that take an already existing OSGi Framework for granted (i.e. the upcomming Blueprint implementation)

So what cannot be done with this runtime?

You cannot take advantage of many of the JavaEE and advanced JBoss features. EJB3, JTA, AOP, etc are not available (yet).
JMX and AOP annotations on MC beans do not work
You cannot deploy existing JBoss applications on that runtime

From the contrast of the two aproaches you see that it would be beneficial to have the benefits of both available in one runtime environment.

The possible future of JBoss OSGi

Conceptually, the Microcontainer already implements the OSGi provided functionality. Some folks even go as far as saying that the MC is a superset of OSGi. The criteria to prove the truth of that claim is well defined, MC "simply" needs to pass the OSGi core TCK.

The idea is to provide the MC with a facade that implements the OSGi core API. Our chief scientist has signed up for it, and I am exited to see what will come out of it. The resulting architecture would then look similar to this

The Microcontainer is the OSGi Framework and manages the classloading scope and lifecycle of all components deployed on it. This is the vision, the time line and details still need to be defined.

That's it for now. Next week I'll be off for a short holiday to my favourite climbing spot

In my next post I'm going to look into the OSGiRuntime abstraction and the Husky Test Harness in more detail. If you like, you can already look forward to Beta3, which should see major improvements to our Blueprint implementation - stay tuned.

May this be useful

JBossOSGi 1.0.0.Beta2 Released

2009-06-03T22:37:00.014+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta2.

You can download it here: jboss-osgi-installer-1.0.0.Beta2.jar

The release comes with improvements in the following areas

JBoss OSGi Runtime has is now a pure OSGi container onto which components, services and applications can be deployed.
Husky Test Framework for remote and embedded OSGi bundle testing
Added support for JMX, JNDI services
Microcontainer service to wire and configure OSGi components

For details please have a look at the latest version of our User Guide.

Here are the change log details

Feature Request

[JBOSGI-70] - Expose bundle headers through JMX

Tasks

[JBOSGI-79] - Provide POM descriptions for bundles
[JBOSGI-86] - Document JBossOSGi Runtime
[JBOSGI-88] - Document JMX Service
[JBOSGI-89] - Document JNDI Service
[JBOSGI-90] - Add hot-deployment to Runtime

Enjoy

OSGi Blueprint Service (RFC-124)

2009-04-23T14:36:00.022+02:00

This post introduces the OSGi Blueprint Service (RFC-124) as it is currently drafted by the OSGi Enterprise Expert Group (EEG). I'll try to present the most relevant information in a fast and easy digestible way such that you should get a good idea of what Blueprint Service is about and why it is relevant for JBossOSGi.

Introduction

The OSGi platform provides an attractive foundation for building enterprise applications. However it lacks a rich component model for declaring components within a bundle and for instantiating, configuring, assembling and decorating such components when a bundle is started.

In 2006 SpringSource, the company behind the Spring Framework started development on a project called Spring Dynamic Modules to address the above needs. In Sep-2007 that project provided the basis for RFC-124 which is now known as "Blueprint Service".

Application Domain

The enterprise Java marketplace revolves around the Java Platform, Enterprise Edition (formerly known as J2EE) APIs. This includes APIs such as JMS, JPA, EJB, JTA, Java Servlets, JSF, JAXWS and others. The central component model of JEE is Enterprise JavaBeans (EJBs). Some core features of the enterprise programming models the market is moving to include:

A focus on writing business logic in “regular” Java classes that are not required to implement certain APIs or contracts in order to integrate with a container
Dependency injection: the ability for a component to be “given” its configuration values and references to any collaborators it needs without having to look them up. This keeps the component testable in isolation and reduces environment dependencies. Dependency injection is a special case of Inversion of Control.
Declarative specification of enterprise services. Transaction and security requirements for example are specified in metadata (typically XML or annotations) keeping the business logic free of such concerns. This also facilitates independent testing of components and reduces environment dependencies.
Aspects, or aspect-like functionality. The ability to specify in a single place behavior that augments the execution of one or more component operations.

In the JBoss Application Server all the core features from above are handled by the JBoss Microcontainer.

Problem Description

Enterprise application developers would like to be able to take advantage of the OSGi platform. The core features of enterprise programming models previously described must be retained for enterprise applications deployed in OSGi. The current OSGi specifications are lacking in the following areas with respect to this requirement:

There is no defined component model for the internal content of a bundle. Declarative Services only supports the declaration of components that are publicly exposed.
The configuration (property injection) and assembly (collaborator injection) support is very basic
There is no model for declarative specification of services that cut across several components (aspects or aspect-like functionality)
Components that interact with the OSGi runtime frequently need to depend on OSGi APIs
The set of types and resources visible from the context class loader is unspecified
Better tolerance of the dynamic aspects of the OSGi platform is required. The programming model should make it easy to deal with services that may come and go, and with collections of such services, via simple abstractions such as an injecting a constant reference to an object implementing a service interface, or to a managed collection of such objects.

Requirements (selected)

The solution MUST enable the instantiation and configuration of components inside a bundle based on metadata provided by the bundle developer.
The solution SHOULD enable the creation of components inside a bundle to be deferred until the dependencies of those components are satisfied.
The solution MUST provide a mechanism for a bundle component to be optionally exported as an OSGic service.
The solution MUST provide a mechanism for injecting a reference to an OSGi service into a bundle component. It SHOULD provide a constant service reference that the receiving component can use even if the target service backing the reference is changed at run time.
The solution SHOULD tolerate services in use being unregistered and support transparent rebinding to alternate services if so configured.
The solution SHOULD provide a rich set of instantiation, configuration, assembly, and decoration options for components

Solution

The runtime components to be created for a bundle, together with their configuration and assembly information, are specified declaratively in one or more configuration files contained within the bundle. A bundle with such information present is known as a managed bundle.

An extender bundle is responsible for observing the life cycle of such bundles. When a bundle is started, the extender creates a module context for that bundle from its blueprint by processing the configuration files and instantiating, configuring, and assembling the components specified there. When a managed bundle is stopped, the extender shuts down the module context, which causes the managed components within the context to be cleanly destroyed.

The declarative configuration for a bundle may also specify that certain of the bundle's managed components are to be exported as services in the OSGi service registry. In addition, it is possible to declare that a bundle component depends on a service or set of services obtained via the service registry, and to have those services dependency injected into the bundle component.

Module Context Life Cycle and the Extender Bundle

Module context creation and destruction

A Blueprint Service implementation must provide an extender bundle which manages the lifecycle of module contexts. This bundle is responsible for creating the module contexts for managed bundles (every ACTIVE managed bundle has one and only one associated module context).

When a managed bundle is stopped, the module context created for it is automatically destroyed. All services exported by the bundle will be unregistered

Lazy Activation

Module context instantiation is triggered when the STARTED event is issued for a given bundle, Therefore the module context for a lazily activated bundle will not be created until a class has been loaded from that bundle.

Manifest Headers for Managed Bundles

The extender recognizes a bundle as a managed bundle and will create an associated module context when the bundle is started if one or both of the following conditions is true:

The bundle path contains a folder OSGI-INF/blueprint with one or more files in that folder with a '.xml' extension.
META-INF/MANIFEST.MF contains a manifest header Bundle-Blueprint.

In the absence of the Bundle-Blueprint header the extender expects every ".xml" file in the OSGI-INF/blueprint folder to be a valid module context configuration file.

Two directives are defined by the blueprint service specification to control the manner in which module context creation occurs. These directives are applied to the Bundle-SymbolicName header.

blueprint.wait-for-dependencies (true|false) - controls whether or not module context creation should wait for any mandatory service dependencies to be satisfied before proceeding (the default), or proceed immediately without waiting if dependencies are not satisfied upon startup.
blueprint.timeout (300000) - the time to wait (in milliseconds) for mandatory dependencies to be satisfied before giving up and failing module context creation.

For example:

Bundle-SymbolicName: org.osgi.foobar;blueprint.wait-for-dependencies:=false

Bundle-SymbolicName: org.osgi.foobar;blueprint.timeout:=60000

Declaring Module Components

The basic structure of a configuration file is as follows:

<components xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"...>
<description>
Optional description for the blueprint defined in this file.
</description>
<component id="..." class="...">
<!-- collaborators and configuration for this component go here -->
</component>
<component id="..." class="...">
<!-- collaborators and configuration for this component go here -->
</component>
<!-- more component definitions go here... -->
</components>

Naming Components

Every component has at most one id. Component ids must be unique within a module.

Implicit Component Definitions

A module context contains a number of implicitly defined components with well-known names.

ModuleContext - provides access to the component objects within the module context
Bundle and BundleContext - represents the bundle and its contextwith which the module context is associated
ConversionService - provides access to the type conversions that are defined for the module context

Instantiating Components

Object instantiation is supported in the following ways:

Using a constructor
Using a static factory method
Using an instance factory method

Dependencies

A typical module is made up of components that work (or collaborate) together. The basic principle behind Dependency Injection (DI) is that objects define their dependencies only through constructor arguments, arguments to a factory method, or properties which are set on the object instance after it has been constructed or returned from a factory method.

Dependency Injection is supported in the following ways:

Constructor Injection
Setter Injection

Type Conversion

String values in module context configuration files must be converted to the type expected by an injection target. The module context container supports a number of type conversions by default, and provides an extension mechanism for configuring additional type converters.

Lazily instantiated components

By default all singleton components in a module context will be pre-instantiated at startup. A lazily initialized component is not created at startup and will instead be created when it is first requested.

Component Scopes

Components can be defined to be deployed in one of a number of scopes, specified using the scope attribute:

Singleton - scopes a single component definition to a single object instance per module context
Prototype - scopes a single component definition to any number of object instances
Bundle - scopes a single component definition to a single object per requesting client bundle

Lifecycle

Specifying an init-method for a component enables a component to perform initialization work once all the necessary properties on a component have been set by the container. Specifying a destroy-method enables a component to get a callback when the module context containing it is destroyed.

Interacting with the Service Registry

The osgi namespace provides elements that can be used to export managed components as OSGi services, to define references to services obtained via the registry.

Exporting a managed component to the Service Registry

The service element is used to define a component representing an exported OSGi service. At a minimum you must specify the managed component to be exported, and the service interface that the service advertises.

For example

<service ref="comp" interface="com.xyz.MessageService"/>

Controlling the set of advertised service interfaces

The simplest mechanism, shown above, is to use the interface attribute to specify a fully-qualified interface name. To register a service under multiple interfaces the nested interfaces element can be used in place of the interface attribute.

<service ref="componentToBeExported">
<interfaces>
<value>com.xyz.MessageService</value>
<value>com.xyz.MarkerInterface</value>
</interfaces>
</service>

Using the auto-export attribute you can avoid the need to explicitly declare the service interfaces at all by analyzing the object class hierarchy and its interfaces. The auto-export attribute can have one of four values:

disabled : the default value; no auto-detected of service interfaces
interfaces : all of the Java interface types implemented by the component
class-hierarchy : component's implementation type and super-types
all-classes : component's implementation type and super-types plus all interfaces implemented by the component.

Controlling the set of advertised properties

Additional service properties can be specified using the nested service-properties element.

<service ref="componentToBeExported" interface="com.xyz.MyServiceInterface">
<service-properties>
<entry key="myOtherKey" value="aStringValue"/>
<entry key="aThirdKey" value-ref="componentToExposeAsProperty"/>
<service-properties>
</service>

The depends-on attribute

The depends-on attribute can be used to provide a comma-delimited list of component names for components that must be instantiated and configured before the service is published to the registry.

Dealing with service dynamics

The component defined by a reference element is unchanged throughout the lifetime of the module context (the object reference remains constant). However, the OSGi service that backs the reference may come and go at any time.

When the service backing a reference component goes away, an attempt is made to replace the backing service with another service matching the reference criteria. If no matching service is available, then the reference is said to be unsatisfied.

When an operation is invoked on an unsatisfied reference component, the invocation blocks until either the reference becomes satisfied or a timeout expires.

Mandatory dependencies

An exported service may depend, either directly or indirectly, on other services in order to perform its function. If one of these services is considered a mandatory dependency and the dependency can no longer be satisfied (because the backing service has gone away and there is no suitable replacement
available) then the exported service that depends on it will be automatically unregistered from the service registry.

Service Listeners

Applications that need to be aware of when a service backing a reference component is bound and unbound, or when a member is added to or removed from a collection, can register one or more listeners using the nested listener element.

For example:

<reference id="someService" interface="com.xyz.MessageService">
<listener bind-method="onBind" unbind-method="onUnbind">
<component class="MyCustomListener"/>
</listener>
</reference>

Namespace Extension Mechanism

Third parties may contribute additional namespaces containing elements and attributes used to configure the components for a module context.

In order to be able to interpret elements and attributes declared in third party namespaces, a namespace handler must be registered that the container can delegate to.

Here an example of a hypothetical "cache" namespace:

<cache:lru-cache id="myCache"/>
<component id="fooService" class="FooServiceImpl" cache:cache-return-values="true">
<cache:exclude>
<cache:operation name="getVolatile"/>
</cache:exclude>
<property name="myProp" value="12"/>
</component>

Credits

Adrian Colyer from SpringSource is the author of the Blueprint Service specification.

Non intrusive OSGi Bundle Testing

2009-04-23T09:14:00.035+02:00

For JBossOSGi I was looking for ways to test bundles that are deployed to a remote instance of the JBossOSGi Runtime. I wanted the solution to also work with an OSGi Framework that is bootstrapped from within a JUnit test case.

The basic problem is of course that you cannot access the artefacts that you deploy in a bundle directly from your test case, because they are loaded from different classloaders.

Most solutions to the problem somehow bring the test case into the OSGi Framework such that it can access the test bundle. They run the test and finally communicate the results back to the test framework. This approach is well documented in Chapter 11 of the Spring Dynamic Modules Reference Guide

Lets have a look at the specific JBossOSGi test requirements

OSGi Framework agnostic
non-intrusive to the test bundle
works for embedded and remote test scenarios
simple and fast to implement

To achieve that it seemed natural to leverage what OSGi provides natively in terms of reporting, which would be the Log Service from the OSGi compendium specification. The approach would work like this

Test Case registers a LogListener with the LogReaderService
Test bundle logs messages to the LogService
Test Case verifies the order and content of the received log messages

The JBossOSGi SPI provides a special LogListener in form of the LogEntryCache to do the log entry caching, filtering and lookup.

But let's talk a little detour into the Log Service from the OSGi compendium specification.

LogService – The service interface that allows a bundle to log information, including a message, a level, an exception, a ServiceReference object, and a Bundle object.

LogEntry - An interface that allows access to a log entry in the log. It includes all the information that can be logged through the Log Service and a time stamp.

LogReaderService - A service interface that allows access to a list of recent LogEntry objects, and allows the registration of a LogListener object that receives LogEntry objects as they are created.

LogListener - The interface for the listener to LogEntry objects. Must be registered with the Log Reader Service.

First a test bundle needs to obtain an instance of the LogService. Here is a bad way of doing this

String sName = LogService.class.getName();
ServiceReference sRef = ctx.getServiceReference(sName);
LogService log = sysContext.getService(sRef);

The code above has two issues

It assumes that there is LogService registered
It does not detect when the LogService disappears

Here is a better way of obtaining the LogService

String sName = LogService.class.getName();
LogService log = new SystemLogService(context);
tracker = new ServiceTracker(context, sName, null)
{
 public Object addingService(ServiceReference reference)
 {
   log = (LogService)super.addingService(reference);
   return log;
 }
 public void removedService(ServiceReference reference, Object service)
 {
   super.removedService(reference, service);
   log = new SystemLogService(context);
 }
};
tracker.open();

The code above initializes the log instance with the SystemLogService that is part of the jboss-osgi-common.jar bundle. The tracker overrides the log instance when an actual LogService gets registered. The tracker restores the SystemLogService, in case the LogService disappears again.

This LogService tracking code is so common that the jboss-osgi-common.jar bundle already contains a tracker which does all of the above. Hence, the best way to obtaining the LogService with JBossOSGi ist

LogService log = new LogServiceTracker(context);

Now that the test bundle actually has an instance of the LogService it can start logging messages to that service. These messages are seen by the LogReaderService that the test case can register a LogListener with.

In the test case you would create a new LogEntryCache and associate one or more LogEntryFilter objects with it.

LogEntryCache logEntryCache = new LogEntryCache();
LogEntryFilter filter = new LogEntryFilter("example-log(.*)", 0, null);
logEntryCache.addFilter(filter);

The LogEntryCache is then added to the LogReaderService using a ServiceTracker similar to the one above. Because the filters are 'or' combined the cache stores log enties that pass at least one filter in the list. Each filter has three filter criteria

A regular expression that matches a Bundle-SymbolicName
A minimum LogLevel, whereas 0 indicates any LogLevel
A regular expression that matches the log message

A test case can now verify the cached log messages like this

List entries = logEntryCache.getLog();
assertEquals("Number of entries", 1, entries.size());
assertEquals("[ServiceA] new Service", entries.get(0).getMessage());

In the remote test scenario it works essentially in the same way, only that a RemoteLogListener sends the LogEnties to a RemoteLogReaderService. The local test case registers it's LogEntryCache with the RemoteLogReaderService.

The actual communication is done with the JBoss Remoting socket transport. Both, the RemoteLogListener and the RemoteLogReaderService are part of the jboss-osgi-remotelog.jar bundle. That bundle needs to be installed with matching properties in the local and the remote OSGi Framework.

org.jboss.osgi.service.remote.log.sender - Enable the server side LogListener
org.jboss.osgi.service.remote.log.reader - Enable the client side LogReaderService
org.jboss.osgi.service.remote.log.host - The remote host that log messages are sent to
org.jboss.osgi.service.remote.log.port - The remote port that log messages are sent to

You may also want to have a look at Chapter 5.2 Remote Log Service of the JBossOSGi User Guide.

In my next post I'm going to look into the Blueprint Service (RFC-124) specification, which provides a rich component model for declaring components within a bundle and for instantiating, configuring, assembling and decorating such components - stay tuned.

May this be useful

JBossOSGi 1.0.0.Beta1 Released

2009-04-22T14:14:00.009+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Beta1.

You can download it here: jboss-osgi-installer-1.0.0.Beta1.jar

The release comes with improvements in the following areas

Added Equinox and Knopflerfish integration
Improved test support for remote and embedded scenarios
A set of installer provided OSGi examples
A bundle for remote and local log message filtering

For details please have a look at the latest version of our User Guide.

Here are the change log details

Tasks

[JBOSGI-28] - Setup OSGi Framework TCK
[JBOSGI-31] - Integration layer for Equinox
[JBOSGI-32] - Integration layer for Knopflerfish
[JBOSGI-59] - Provide initial Examples
[JBOSGI-63] - Update to Felix HTTP Service (Jetty) 1.0.0
[JBOSGI-64] - Update to Felix Log Service 1.0.0
[JBOSGI-65] - Update to Felix 1.6.0

Bugs

[JBOSGI-36] - Bundle classes leak into system classloader
[JBOSGI-37] - Prevent creation of deployment unit for nested jars
[JBOSGI-40] - Cannot run embedded tests with SecurityManager

Enjoy

JBossOSGi - First Release

2009-03-30T10:56:00.006+02:00

I am happy to announce the release of JBossOSGi-1.0.0.Alpha3.

You can download it here: jboss-osgi-installer-1.0.0.Alpha3.jar

JBossOSGi-1.0.0.Alpha3 is our first functional release that comes with:

Apache Felix integration
A specialized JBossOSGi Runtime
Integrated Hudson QA
IzPack based Installer
Bundle hot deployment
Management Console
Docbook Guides
HttpService
LogService

You may also what to have a look at the JBossOSGi Diary blog posts

Here are the change log details

Tasks

[JBOSGI-29] - Provide Initial Framework SPI
[JBOSGI-30] - Integration layer for Apache Felix
[JBOSGI-35] - Setup JBoss OSGi download area
[JBOSGI-38] - Investigate bundle install/start behaviour with random deployment order
[JBOSGI-41] - Verify persistent file storage
[JBOSGI-42] - Provide IzPack based Installer
[JBOSGI-43] - Hudson QA as integral part of each project release
[JBOSGI-44] - Provide bundle hot-deployment on jboss
[JBOSGI-45] - Provide minimal JBossOSGi Runtime
[JBOSGI-46] - Integrate 3rd party HttpService
[JBOSGI-47] - Delegate 3rd party framework logging to jboss logging
[JBOSGI-48] - Integrate 3rd party LoggingService
[JBOSGI-49] - Integrate 3rd party Management Console
[JBOSGI-50] - Provide a docbook guides
[JBOSGI-51] - Provide a management view (JMX) on framework and bundles

Enjoy

JBossOSGi - Provided Services

2009-03-27T11:34:00.013+01:00

This is the last of a the current series of three blogs on JBossOSGi

Logging Service

The JBossOSGi jboss-osgi-service-logging.jar bundle contains a simple Logging Bridge Service to JBoss Logging. It registers a trivial LogListener with the LogReaderService in case that service is registered with the Framework.

LogListener - Subscribes to LogEntry objects
LogReaderService - Retrieve LogEntry objects

The LogReaderService is part of the standard OSGi Compendium Services. JBossOSGi currently uses the (not yet released) LogService from Apache Felix, which gets deployed as Bundle org.apache.felix.log.jar

The LogListener itself logs messages under the Bundle's symbolic name.

You can therefore change the logging for specific Bundles by setting the respective logging level.

Microcontainer Service

JBossOSGi SPI comes with a service that give access to the JBoss Microcontainer Kernel and the JMX MBeanServer. The service is registered with the Framework under the name

org.jboss.osgi.service.MicrocontainerService

Here is an example of how an OSGi component can register an arbitrary MBean with the MBeanServer.

String sname = MicrocontainerService.class.getName();
ServiceReference sref = context.getServiceReference(sname);
MicrocontainerService service = context.getService(sref);
MBeanServer server = service.getMbeanServer();
server.registerMBean(new Foo(), OBJECT_NAME);

What is there to come?

The intention of this post was to give information on the JBossOSGi Provided Services. This concludes this series of three blogs. I look forward to your feedback on the JBossOSGi User Forum

In my next post I'm hopefully going to write about the JBossOSGi integration for Equniox and Knopflerfish - stay tuned.

JBossOSGi - Service Provider Interface

2009-03-27T11:31:00.019+01:00

This is the second of a the current series of three blogs on JBossOSGi

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.

org.jboss.osgi.service - SPI provided services
org.jboss.osgi.spi - Common classes and interfaces
org.jboss.osgi.spi.framework - Framework integration
org.jboss.osgi.spi.junit - JUnit test integration
org.jboss.osgi.spi.management - Management view

Bootstrapping JBossOSGi

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 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.

JBossOSGi - Getting Started

2009-03-27T11:25:00.038+01:00

This is the first of a the current series of three blogs on JBossOSGi

Installing JBossOSGi

JBossOSGi is distributed as an IzPack installer archive. The installer is available from the JBossOSGi download area.

To run the installer execute the following command:

 java -jar jboss-osgi-installer-1.0.0.Alpha3.jar

The installer first shows a welcome screen

Then you select the installation path for the JBossOSGi distribution. This is the directory where you find the binary build artifacts, the java sources, documentation and the JBossOSGi Runtime.

The installer contains multiple installation packs. Greyed packs are required, others are optional and can be deselected.

JBossOSGi Distribution - Documentation, Binary Artifacts and Sources
JBossOSGi Runtime - Standalone JBossOSGi Runtime based on JBossAS
JBossOSGi Integration - Integration with an existing JBossAS instance

In case you have selected 'JBossOSGi Integration', you will be presented with the choice of supported target containers.

You will then have to point the installer to your existing JBossAS installation.

You can then verify the selected installation options and proceed with the actual installation.

The installer reports its installation progress and finally displays a confirmation screen. You can now optionally generate an "automatic installation script" that you can use when you want to repeat what you have just done without user interaction.

JBossOSGi Runtime

If you selected 'JBossOSGi Runtime' during installation you should see a runtime folder, which contains the JBossOSGi Runtime distribution.

The JBossOSGi Runtime is a customized version of the JBoss Application Server. From that we removed the services that are not absolutely necessary to run the installed OSGi Framework. Consequently, you can start the JBossOSGi Runtime in the same way as you start JBossAS.


[tdiesler@tdvaio runtime]$ bin/run.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /usr/java/jboss-osgi-1.0.0.Alpha3/runtime
...
=========================================================================
[ServerImpl] Starting JBoss (Microcontainer)...
...
[FelixIntegration] OSGi Integration Felix - 1.0.0.Alpha3
[FelixIntegration] Installed bundle: org.osgi.compendium
[FelixIntegration] Installed bundle: org.jboss.osgi.service.logging
[FelixIntegration] Started bundle: org.osgi.compendium
[FelixIntegration] Started bundle: org.jboss.osgi.service.logging
[OSGiDeployer] Installed: jboss-osgi-service-webconsole [3][INSTALLED]
[OSGiDeployer] Installed: org.apache.felix.bundlerepository [4][INSTALLED]
[OSGiDeployer] Installed: org.apache.felix.configadmin [5][INSTALLED]
[OSGiDeployer] Installed: org.apache.felix.http.jetty [6][INSTALLED]
[OSGiDeployer] Installed: org.apache.felix.log [7][INSTALLED]
[OSGiDeployer] Installed: org.apache.felix.metatype [8][INSTALLED]
...
[ServerImpl] JBoss (Microcontainer) [5.0.1.GA] Started in 11s:645ms

Bundle Deployment

Bundle deployment works, as you would probably expect, by dropping your OSGi Bundle into the JBossOSGi Runtime deploy folder.

cp .../test-libs/jbosgi36-bundle.jar .../server/default/deploy

[OSGiDeployer] Installed: jbosgi36 [9][INSTALLED]
[jbosgi36] BundleEvent INSTALLED
[jbosgi36] BundleEvent RESOLVED
[jbosgi36] ServiceEvent REGISTERED
[jbosgi36] BundleEvent STARTED
[BundleStartStopDeployer] Started: jbosgi36 [9][ACTIVE]

Managing installed Bundles

JBossOSGi comes with a simple Web Console, which is currently based on the Apache Felix Web Console project. By default the JBossOSGi Web Console is available at

http://localhost:8090/jboss-osgi.

Hudson QA Environment

Setup the Hudson QA Environment

The JBossOSGi Hudson QA Environment is an integral part of the JBossOSGi code base. It is designed for simplicity because we believe that comprehensive QA will only get done if it is dead simple to do so.

Consequently, you only have to execute two simple ant targets to setup the QA environment that was used to QA the JBossOSGi release that you currently work with.

If in future we should discover a problem with a previous JBossOSGi release, it will be possible to provide a patch and verify that change using the original QA environment for that release.

With every release we test the matrix of supported target containers and JDKs.

Set Hudson Properties

You need to set a few properties, especially these

hudson.maven.path
hudson.username
hudson.password
hudson.root

Run Hudson Setup

[tdiesler@tdvaio hudson]$ ant hudson-setup

hudson-setup:
[copy] Copying 2 files to /home/.../hudson/jboss-osgi/apache-tomcat
...
[echo]
[echo] *************************************
[echo] * Hudson setup successfully         *
[echo] * ant hudson-start                  *
[echo] *************************************
[echo]

Run Hudson Start

[tdiesler@tdvaio hudson]$ ant hudson-start

hudson-start:
[echo]
[echo] *************************************
[echo] * Hudson started successfully       *
[echo] * http://localhost:8280/hudson      *
[echo] *************************************
[echo]

Run Hudson Stop

[tdiesler@tdvaio hudson]$ ant hudson-stop

hudson-stop:
[echo]
[echo] *************************************
[echo] * Hudson stopped successfully       *
[echo] * ant hudson-start                  *
[echo] *************************************
[echo]

What is there to come?

The intention of this blog post was to provide folks with the information to get started with JBossOSGi.

In my next post I'm going to write about the JBossOSGi Service Provider Interface - stay tuned.

JBossOSGi - Technology Overview

2009-02-12T11:15:00.004+01:00

The Open Services Gateway Initiative (OSGi), specifications define a standardized, component-oriented, computing environment for networked services that is the foundation of an enhanced service-oriented architecture.

The OSGi specification defines two things:

A set of services that an OSGi container must implement
A contract between the container and your application

Developing on the OSGi platform means first building your application using OSGi APIs, then deploying it in an OSGi container.

What does OSGi offer to Java developers?

OSGi modules provide classloader semantics to partially expose code that can then be consumed by other modules. The implementation details of a module, although scoped public by the Java programming language, remain private to the module. On top of that you can install multiple versions of the same code and resolve dependencies by version and other criteria. OSGi also offers advanced security and lifecycle, which I'll explain in more detail further down.

What kind of applications benefit from OSGi?

Any application that is designed in a modular fashion where it is necessary to start, stop, update individual modules with minimal impact on other modules. Modules can define their own transitive dependencies without the need to resolve these dependencies at the container level. The OSGi platform builds an exellent foundation for the next generation JBoss ESB for example.

Should Java EE developers adopt the OSGi programming model?

Probably not. The OSGi runtime may be used internally by Java EE container providers to achieve the desired isolation and configuration flexibility that the container whishes to provide. At the application programming level, the Java EE model will continue to exist in its own right, wheras the OSGi model may provide the more suitable runtime environment for applications that require the modular isolation, security and lifecycle management that OSGi offers.

OSGi Framework Overview

The functionality of the Framework is divided in the following layers:

Security Layer
Module Layer
Life Cycle Layer
Service Layer
Actual Services

The OSGi Security Layer is an optional layer that underlies the OSGi Service Platform. The layer is based on the Java 2 security architecture. It provides the infrastructure to deploy and manage applications that must run in fine grained controlled environments.

The OSGi Service Platform can authenticate code in the following ways:

By location
By signer

For example, an Operator can grant the ACME company the right to use networking on their devices. The ACME company can then use networking in every bundle they digitally sign and deploy on the Operator’s device. Also, a specific bundle can be granted permission to only manage the life cycle of bundles that are signed by the ACME company.

The OSGi Module Layer provides a generic and standardized solution for Java modularization. The Framework defines a unit of modularization, called a bundle. A bundle is comprised of Java classes and other resources, which together can provide functions to end users. Bundles can share Java packages among an exporter bundle and an importer bundle in a well-defined way.

Once a Bundle is started, its functionality is provided and services are exposed to other bundles installed in the OSGi Service Platform. A bundle can carry descriptive information about itself in the manifest file that is contained in its JAR file. Here are a few important Manifest Headers defined by the OSGi Framework:

Bundle-Activator - class used to start, stop the bundle
Bundle-SymbolicName - identifies the bundle
Bundle-Version - specifies the version of the bundle
Export-Package - declaration of exported packages
Import-Package - declaration of imported packages

The notion of OSGi Version Range describes a range of versions using a mathematical interval notation. For example

Import-Package: com.acme.foo;version="[1.23, 2)", com.acme.bar;version="[4.0, 5.0)"

With the OSGi Class Loading Architecture many bundles can share a single virtual machine (VM). Within this VM, bundles can hide packages and classes from other bundles, as well as share packages with other bundles.

For example, the following import and export definition resolve correctly because the version range in the import definition matches the version in the export definition:

A: Import-Package: p; version="[1,2)"
B: Export-Package: p; version=1.5.1

Appart from bundle versions, OSGi Attribute Matching is a generic mechanism to allow the importer and exporter to influence the matching process in a declarative way. For example, the following statements will match.

A: Import-Package: com.acme.foo;company=ACME
B: Export-Package: com.acme.foo;company=ACME;
security=false

An exporter can limit the visibility of the classes in a package with the include and exclude directives on the export definition.

Export-Package: com.acme.foo; include:="Qux*,BarImpl";
exclude:=QuxImpl

The Life Cycle Layer provides an API to control the security and life cycle operations of bundles.

A bundle can be in one of the following states:

A bundle is activated by calling its Bundle Activator object, if one exists. The BundleActivator interface defines methods that the Framework invokes when it starts and stops the bundle.

A Bundle Context object represents the execution context of a single bundle within the OSGi Service Platform, and acts as a proxy to the underlying Framework. A Bundle Context object is created by the Framework when a bundle is started. The bundle can use this private BundleContext object for the following purposes:

Installing new bundles into the OSGi environment
Interrogating other bundles installed in the OSGi environment
Obtaining a persistent storage area
Retrieving service objects of registered services
Registering services in the Framework service
Subscribing or unsubscribing to Famework events

The OSGi Service Layer defines a dynamic collaborative model that is highly integrated with the Life Cycle Layer. The service model is a publish, find and bind model. A service is a normal Java object that is registered under one or more Java interfaces with the service registry.

The OSGi Service Compendium

The OSGi Service Compendium specifies a number of services that may be available in an OSGi runtime environment. Although the OSGi Framework specification is useful in itself already, it only defines the OSGi core infrastructure. The services defined in the compendium specification define the scope and functionality of some common services that bundle developers might want to use. Here is a quick summary:

The Log Service provides a general purpose message logger for the OSGi Service Platform. It consists of two services, one for logging information and another for retrieving current or previously recorded log information.

The Http Service supports two standard techniques for registering servlets and resources to develop communication and user interface solutions for standard technologies such as HTTP, HTML, XML, etc.

The Device Access specification supports the coordination of automatic detection and attachment of existing devices on an OSGi Service Platform, facilitates hot-plugging and -unplugging of new devices, and downloads and installs device drivers on demand.

The Configuration Admin service allows an Operator to set the configuration information of deployed bundles.

The Metatype Service specification defines interfaces that allow bundle developers to describe attribute types in a computer readable form using so-called metadata.

The Preferences Service allows storage of data that is specific to a particular user.

Bundles can use the User Admin Service to authenticate an initiator and represent this authentication as an Authorization object. Bundles that execute actions on behalf of this user can use the Authorization object to verify if that user is authorized.

The Wire Admin Service is an administrative service that is used to control a wiring topology in the OSGi Service Platform. It is intended to be used by user interfaces or management programs that control the wiring of services in an OSGi Service Platform.

The IO Connector Service specification adopts the Java 2 Micro Edition (J2ME) javax.microedition.io packages as a basic communications infrastructure.

The UPnP Device Service specifies how OSGi bundles can be developed that interoperate with UPnP (Universal Plug and Play) devices and UPnP control points.

The Declarative Services specification addresses some of the complications that arise when the OSGi service model is used for larger systems and wider deployments, such as: Startup Time, Memory Footprint, Complexity. The service component model uses a declarative model for publishing, finding and binding to OSGi services.

The Event Admin Service provides an inter-bundle communication mechanism. It is based on a event publish and subscribe model, popular in many message based systems.

The Deployment Admin Service specification, standardizes the access to some of the responsibilities of the management agent: that is, the lifecycle management of interlinked resources on an OSGi Service Platform.

The Auto Configuration Specification is to allow the configuration of bundles. These bundles can be embedded in Deployment Packages or bundles that are already present on the OSGi Service Platform.

The Application Admin Service is intended to simplify the management of an environment with many different types of applications that are simultaneously available.

The DMT Admin Service specification defines an API for managing a device using concepts from the OMA DM specifications.

The Monitor Admin Service specification outlines how a bundle can publish Status Variables and how administrative bundles can discover Status Variables as well as read and reset their values.

The Foreign Application Access specification is to enable foreign application models like MIDP, Xlets, Applets, other Java application models to participate in the OSGi service oriented architecture.

The Service Tracker specification defines a utility class, ServiceTracker, that makes tracking the registration, modification, and unregistration of services much easier.

The XML Parser Service specification addresses how the classes defined in JAXP can be used in an OSGi Service Platform.

The Position Specification provides bundle developers with a consistent way of handling geographic positions in OSGi applications.

The Measurement and State Specification provides a consistent way of handling a diverse range of measurements for bundle developers.

This Execution Environment Specification defines different execution environments for OSGi Server Platform Servers.

What is there to come?

The intention of this initial blog was to provide folks that have not yet come in contact with this exciting technology a brief overview of what OSGi has to offer. I barely scratched the surface of what this all entails - may it still be useful.

In my next blog I'm going to write about the JBossOSGi Service Provider Interface (SPI) and how we integrate Apache Felix to provide an OSGi runtime based on the Microcontainer. You will learn about JBossOSGi Deployers and how to use the JBossOSGi HttpService to setup an Http endpoint. As prove of concept we run the Apache Felix Web Console on JBossWeb and use it to manage the JBossOSGi Runtime - stay tuned.

References

[1] Hello, OSGi, Part 1: Bundles for beginners
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html
[2] OSGi Business WhitePaper
http://www.osgi.org/wiki/uploads/Links/OSGiBusinessBenefitsWhitepaper.pdf
[3] OSGi Technical WhitePaper
http://www.osgi.org/wiki/uploads/Links/OSGiTechnicalWhitePaper.pdf