fmeschbe's blog

OSGi DevCon 2013 once again is co-located with EclipseCon 2013 taking place in Boston, Massachusetts, between March 25 to 28. See the OSGi Alliance announcement for full details. The call for papers is still open until November 19, so hurry up and submit a talk. For teasers an early bird selection has been taken: Modularity in the Cloud: a Case Study by by Paul Bakker and Marcel Offermans from Luminis. Hop to see you next March in Boston.

At times you want (or need) to include third party libraries in your bundles. You basically have two options to do that: Embed the complete library Inline the required classes/packages (or everything) Until recently I was in the camp of embedding the complete libraries and setting the Bundle-ClassPath manifest header accordingly. The Embed-Dependency directive of the Apache Felix Maven Bundle Plugin makes this extremely easy to do. Lately, though, this has been questioned by Karl Paul's pojosr project. This project brings the OSGi Service Registry to regular applications. The nice thing here is, that it really is a stripped down OSGi Framework basically removing the modularity pillar. The drawback is that this causes the Bundle-ClassPath manifest header and embeddeded libraries to not be supported. Thus to run your regular bundle inside pojosr, you will have to inline all third party libraries instead of embedding them. The upside is that this really works. For example the Apac...

After subscribing to the OSGi Planet feed I felt like starting to read some old blog posts and stumbled upon a series of posts by BJ Hargave around the issues of the Eclipse ContextFinder caused by the Class.forName methods. For the full story please go and read Class.forName caches defined class in the initiating class loader (and folow the links !). So, these posts caused me to try and look how we behave in Apache Sling ... and of course hoped we would be clean. Well, hmm, turns out we are not ... I found nine classes using Class.forName . So we probably have to clean this up. Maybe or maybe not, these uses may be the cause for some strange failures we had over time. I cannot really tell. But I cannot exclude this possibility either. BTW, this is what I did to find the classes: $ find . -name "*.java" -exec fgrep -l Class.forName {} \;

I have been thinking about using version numbers lately while working on some API extension of the Sling Engine bundle. So here is what I think versions are all about and that we all should be very careful when changing code and assigning versions to it. On a high level versions have various aspects: Syntax There is no global agreement on the correct syntax of versions. I tend to like the OSGi syntax specification: The version has four parts separated by dots. The first three parts are numbers, called the major, minor and micro version. The fourth part is a plain (reduced character set) string which may be used to describe a particular version. Version numbers are compared as you would expect, except that the fourth part is employs case-sensitive string comparison comparing the actual Unicode codepoints of the characters. Semantic The semantics of a version define what it means to increment each place of a version. In the world of software development there is even less agreemen...

In the Apache Sling project we have an interesting problem : Knowing when the application has finished its startup. Coming from a background of a traditional application, you know when the system has finished its startup. For example, a servlet container knows it has finished the startup, when all web applications have been started. In Apache Sling, the situation is a bit different: Apache Sling is an extensible system, where extensions may simply be added by adding more bundles. "Easy", you say, "just wait for all bundles to have been started and you know when the application is ready". True, but there is a catch. To extend Apache Sling, you register services with the OSGi registry. "Still easy", you might say. Right, if the services are all started by bundle activators, we still can depend on having all bundles started for the system to be ready. Again, this is only part of the story: Some services depend on other services. So the dependent services may...

The OSGi framework and its compendium services provide a whole lot of fun to build applications. Defining bundles is a cool stuff to cut the big job into pieces and enjoy the coolness of separation of concerns just like the old Romans said: Divide et Impera ! One interesting compendium specification is the Declarative Services Specification. This specification tries and IMHO succeeds very well to bring some of the cool stuff of Spring, namely Dependency Injection, into the OSGi world. Just like the application descriptors in Spring you have component descriptors in Declarative Services. Using a component descriptor, you define the following properties of a component: The name of the component and whether it is activated immediately or not Whether the component is a service and the service interfaces to register the component with Which other services are used by the component. These services may be injected (bound in OSGi speak) or may be looked up. There is also the notion of mandator...

In a previous post I explained how to extend an OSGi framework such that more classes are visible inside the framework from the outside world. This posting provided a very simple example to generate Framework Extension Bundle using a single file and calling the JAR tool from the command line. Here I will expand on this example by creating a Maven 2 project, which may be used in environments where Maven 2 is used for project builds. As a first step, we need a Maven 2 project descriptor. To create this beast, we have to decide, how we build the project. I generally use the Apache Felix Maven Bundle Plugin to build my projects as OSGi bundles. This great plugin comes with support for Maven 2 packaging but also provides goals to call if the packaging functionality should not be used. Before talking too much, let me just present a project descriptor, which I know works. After that I will explain why I did it, like I did it. <project xmlns="http://maven.apache.org/POM/4.0.0" ...

Imagine your great application running inside an OSGi framework such as Apache Felix or Eclipse Equinox and requiring a class, which you know is provided by the Java Platform but not provided inside the framework. For example, you provide functionality for the general user on the Internet to submit comments or register themselves but you want to protect this functionality from robots. To do this, you include a Captcha and decided to use the simple java captcha library from SourceForge. This library requires classes from the com.sun.image.codec.jpeg package. This package is generally not made visible inside the framework. So, what can you do ? Of course you could configure your OSGi framework to just make the package visible by configuring either the org.osgi.framework.system.packages or the org.osgi.framework.bootdelegation property accordingly. But what if you can't do that ? Here come the so-called Extension Bundles. Extension Bundles are actually Fragment Bundles, which a...