OSGI on ilikeorangutans

OSGI, Guice, and Peaberry: first steps

Wed, 27 Feb 2013 13:59:40 -0400

Introduction

I’ve been trying to get Google Guice and Peaberry to work in my OSGI projects for a while. Google Guice is a great dependency injection framework, and Peaberry promises to bridge the gap between OSGI services and dependency injection.

However, getting Peaberry to work was not trivial, mostly because there aren’t many docs and the quality of the docs is somewhat lacking. The best piece is still this pdf Peaberry - blending services and extensions, but it’s a lot of information in very little space.

Type Incompatibility With Maven SCR Plugin

Wed, 06 Feb 2013 13:59:40 -0400

Yesterday I ran into a most strange error when compiling one of my OSGI bundles:

[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.7.4:scr (generate-scr-scrdescriptor) on project XXX: A type incompatibility occured while executing org.apache.felix:maven-scr-plugin:1.7.4:scr: com.thoughtworks.qdox.model.Annotation cannot be cast to java.util.List

I saw several variations of that error and was initially clueless as how to fix it. However, I eventually found the problem:

@Service(value = { MyService.class, ManagedService.class })
@Component(immediate = true)
@Properties(@Property(name = "foo", value = "bar"))
public class NissanAutoDataUrlGenerator implements ManagedService { }

The mistake is that the @Properties annotation takes an array as it’s parameter. Eclipse does not mark the above as an error, however, the Maven plugin is not happy about it. Here’s the correct code:

Apache Sling Resource Resolver Rules in a Nutshell

Tue, 20 Nov 2012 13:59:40 -0400

If you work with Apache Sling, you have probably encountered the ResourceResolver and its configuration rules. In short, the ResourceResolver is the part of Sling that resolves incoming requests to actual or virtual resources. For example, if a request for /foo/bar is coming in the resolver will resolve that to a corresponding node in the JCR. However, sometimes it is not desireable to expose the internal structure of the repository or the required external structure cannot be represented using the JCR. In that case the resolver can be customized by installing resolver rules. Resolver rules can be modified via the OSGI configuration editor or the OSGI ConfigurationAdmin.

commons-logging in OSGI Environments

Wed, 14 Nov 2012 13:59:40 -0400

While working on a small toy project using Apache Felix and commons-httpclient, I kept running into the issue that there is no official OSGI bundle for Apache commons-logging out there. While most Apache commons projects either provide simple bundles or full blown OSGI implementations with Activators and Services, commons-logging is an interesting exception. If you scan the Commons OSGI status page, you will notice that there is no OSGI version for commons-logging available, and a separate section to explain why. I haven’t dug into why and how it conflicts with the OSGI classloading scheme, but I can see that being a problem. Be it as it may, there is no official OSGI bundle for commons logging.

OSGI Bootstrapping

Tue, 23 Oct 2012 13:59:40 -0400

I’ve been working with OSGI based technology for a while now and it’s a great piece of technology. However, so far I’ve only worked with OSGI technology that runs in existing instances of the framework. A running framework is easy to deal with, but how do you get to this point? I spent some time today playing with that, and it took me a while to put it all together. So naturally, I’ll have to record my findings here.

OSGI Classloading Reading List

Fri, 12 Oct 2012 13:59:40 -0400

I’ve been doing a lot of reading on how OSGI handles class loading. I’m starting to fully understand and leverage OSGI and I’m trying to keep my framework Object Mapper as compatible with OSGI as I can.

In OSGI classloading is very restricted, similar to what happens in enterprisy Java application servers, and completely unlike traditional Java applications where everything shares a single classloader. In OSGI each bundle has its own classloader and what is visible accross the bundle boundaries is subject to strict export rules. In order to use a class outside of a bundle you’ll have to explicitly declare its package as exported. There are many benefits to this strict architecture, clean architectures, reusable components and the ability to update bundles at runtime are probably the most important ones.