Spring DM with Annotations

A couple of days ago, I implemented a sample application, based on Spring Dynamic Modules (DM) 1.2.0, with its annotation extension. Unfortunately the documentation doesn't contain any sample code, which might cause some unnecessary work, if you are not too familiar with Spring DM.

Spring DM's annotation extension allows you to pull in an OSGi service reference by annotating a setter of a property:


Unfortunately, you don't get rid of the XML configuration completely, but that's not so bad after all, because you still want to let Spring to all your wiring:


In addition to the instantion part, you need to configure a BeanPostProcessor. It tells Spring to handle your methods annotated with @ServiceReference. If you want all your bundles to use annotations, this might get a little tedious. That's why you can configure annotation processing for all bundles, by defining a fragment bundle, which overrides the default configuration of Spring DM's extender:


Unfortunately, the configuration of the fragement bundle is not in the offical documentation.

Now, that you've got a glimpse of how to use annotations with Spring DM and the ways of configuring it, you might ask whether you want to use it or not? For me this boils down to the question, whether you want to have your dependencies in your xml file or in your code?

It's a tricky question and I think annotations only bring real value, if they make your life easier. Let's take a look at Spring's Web MVC for example: before annotations were introduced, you had to implement an interface in order to code a controller and thus you had dependencies on javax.servlet in your controller code. Spring Web MVC's annotation approach still leaves you with the dependency on Spring, but eliminates the javax.servlet dependency.

In addition to that, it improves testability of controller classes significantly, which I think is worth living with the dependency on Spring.

I think, that the features of Spring DM annotations, at least at the moment, are not compelling enough to have dependencies on it in your code. With the right tooling, Spring's XML configuration should be as easy to handle as annotations.

Book Review Dynamic Modules for OSGi

Apress was kind enough to pass me a copy of this book, which I agreed to review in return.

I have been sitting on Pro Spring Dynamic Modules for Osgi(tm) Service Platforms for a while, although I got a fresh copy right after if was released earlier this year.

One reason for this might be, that after reading the first chapter, it felt like I was reading a manual rather than a book. Personally, I like a little bit more subjectiveness, because it improves the reading experience significantly. The author should spice up the dry material, so you won't get bored that easily. Unfortunately, that's what happened to me - I got bored. However, let's turn the spotlight to the content of the book.

The introduction chapter on OSGi is sufficient to get you up to speed. There are about 60 pages of Spring introduction. However, I think you should at least have some practical experiences with Spring, before digging into Spring Dynamic Modules or even Spring DM Server. It's simply not enough to explain the technicalities, to get someone an understanding of what Spring an its concepts is all about.

There's lot's of code in the book, which you can download and play with. If you like to read code, printed in a book, you are probably gonna like "Pro Spring Dynamic Modules for Osgi". For me, a book is not the preffered media to consume code. I have nothing against small code samples, but having pages over pages full of code, is really confusing and hurts readability.

The manual kind of feeling of the book continues the further you keep reading. Let me give you a concrete example: In chapter 4, called "Spring Dynamic Modules for OSGi", the author explains how the scope attribute of a bean declaration works:


Unfortunately, the how is all there is to the explanation. I expected a real life example of when to use the scope attribute and where it might not be suitable. I do understand, that the book can't go into details all the time, but especially those powerful Spring DM features like scoping, deserve more spotlight. Most of the time, the book stops when it gets interesting and you are left with your own imagination of how to apply that particular feature.

Despite the criticism, I got some neat tips from the book. The author suggests to split the OSGi dependent and traditional Spring configuration to make life easier for testing and mocking. I also gained a lot of knowledge from chapter 6, called "Versioning with OSGi and Spring". The author explains the concepts and implementation of versioning most of the time in a very understandable manner.

Overall, I think Pro Spring Dynamic Modules for Osgi(tm) Service Platforms is a reasonable reference book, with a nice sample application. If you are new to Spring and OSGi, you might have a hard time understanding the use case for those technologies, so I'd suggest to get this book as an addition to some basic reading material.

Spring DM Web Extender Problems

In my current project, I'm evaluating moving a large and very old code base to OSGi. Part of that is getting the the development team on board. I'm trying to point out, how much you can benefit from designing your application with OSGi in mind and the advantages you can have, running your application in an OSGi container.

I created some sample code with the help of the book "Pro Spring Dynamic Modules for Osgi(tm) Service Platforms" to highlight some of my OSGi presentation bulletpoints. One of the samples is running Tomcat inside of Equinox together with Spring Dynamic Modules. Although the sample is really simple and I sticked to the steps in the book precisely, Equinox spit out the following Exception:


After various failed attempts to google for a solution, I decided to consult the book again. Although, I thought I sticked to the steps closely, I missed an important point: start levels.

A start level is simply a non-negative integer value. The Framework has an ‘active start level’ that is used to decide which bundles can be started. Bundles themselves have an associated ‘bundle start level’ which is used to determine when a bundle is started. The bundles at a given start level will all have their start method completely executed before any bundles at a higher level are started. When booted, the Framework monotonically goes through each start level and starts relevant bundles (all the way until the active start level is met).
...
In the end, start levels are there to simply determine the start order of bundles.

I missed the fact that there is a start order in my Equinox run configuration. The bundles, which are in charge of bootstrapping Tomcat, need to be activated in special order, otherwise the previously mentioned Exception is raised. In particular the following bundles need to start in order:

...
org.springframework.osgi.catalina.osgi@3:start, \
org.springframework.osgi.catalina.start.osgi@3:start, \
org.springframework.bundle.osgi.web.extender@4:start, \ 
...

In "Pro Spring Dynamic Modules for Osgi" the config only orders the bundles and doesn't add any explicit start levels. However, I still ran into the same Exception from time to time, depending on other bundles I loaded. I put explicit start levels in my run configuration to solve those problems.

Java 7, Jigsaw and the Missing JSR

A couple of weeks ago, at Devoxx, Mark Reinhold released some details about what's in scope for Java 7, as well as its planned release timeframe. Joe Darcy blogged about this before, so I'm not gonna recap all of the stuff. Instead I'll try to summarize my understanding of the Devoxx kenyote as well as the BOF with Mark and Alex Buckley.

The most interesting Java 7 announcement for me was the proposed language changes, which are steered by Sun. The Devoxx whiteboards as well as the keynote by Mark Reinhold suggested various "small improvements". Among others are:

a for-each construct for Maps

a for-each iteration control

an array-like list/map access

type inference on generics declaration

multicatch of Exceptions

resource management

For further details check Stephen Colebourne's slides.

My understanding is that those changes are not set in stone. Josh Bloch told me that Sun is still gathering feedback from the community, on which changes to implement. However, eventually it's up to Sun which changes to include and how to implement them. One thing is for sure though: Closures are not going to be in Java 7. I won't go into this again. I simply think and I'm not alone on this, it is a missed opportunity for Java.

If you didn't attend Devoxx and look for a way to give feedback on the proposed changes, check out my poll and make your voice heard.

Modularization is another topic, which was mentioned by Mark in his keynote. Like me, you've probably heard about Sun's plans to split up the JRE's libraries into separate modules. What surprised me though, was the fact that this effort won't be specified and implemented by a JSR, but rather an open source project called Jigsaw. According to Mark there is no time for a JSR.

Jigsaw will be a module system, which bootstraps the JRE. It's available to developers as well, to modularize applications, similar to OSGi. Speaking of which, my understanding is that Sun wants to work with OSGi. How this is going to look like, is yet to be determined.

I think it's quite difficult to work on something like a module system without a proper specification. Let's say you want to port your application, which is based on Equinox and OSGi, to the new Java 7 module system. How is this supposed to work? Is this going to work at all? If it's technically possible, I think OSGi will eventually support Java 7 modules. However, I find it rather odd that there's no spec for this endeavor.

Despite all of my rants here there is at least JSR 294, which specifies the language and JVM changes. Don't get me wrong, I'm not a spec freak. I just think that for interoperability and compatibility with other module systems a spec is a necessity. In my current project we invested a lot of work in OSGi. I just don't like the fact that those efforts are probably in vain, if we would like to use Jigsaw instead. I know it's a little far-fetched, but I'm just thinking it should be possible to switch module systems.

In general I like where Java 7 is going. Language changes are finally starting to take shape and Sun's efforts to modularize the JRE, however they might turn out, sound promising.


Eclipse RCP and Inversion of Control

I guess you all heard of Dependency Injection (DI) and Inversion of Control (IoC). To refresh our memories, Wikipedia defines the two terms as follows:

Dependency Injection refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency.

Inversion of control, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to the traditional architecture of software libraries.

For me those two terms have always described the way a framework is wiring your components at startup, no matter if that framework is called PicoContainer, Spring or Guice. It is in control of creating and passing the dependencies to your application, in order for it to run.

The wiring is usually done in the main method of your application or a ContextListener, in case of a webapp. If you are using Spring, for example, you would create an ApplicationContext, which bootstraps the dependencies of your entry point class:

ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
Service s = ctx.getBean("calculationService"); // wires all dependencies
s.start(); // everything is setup already


One of the reasons I like Spring and this particular DI / IoC notion, is that there is no need for creating instance with the new operator. After the initial setup your application is good to go and your dependencies are fully initialized. In webapps this usually works like a charm. In desktop applications, especially if you are using an application framework, it's a little different.

I'm working on a Eclipse RCP desktop app at the moment and combining it with my notion of DI / IoC turns out to be virtually impossible. One of the reasons is OSGi, the underlying technology of the Eclipse RCP. The nature of OSGi is highly dynamic. Bundles and thus dependencies can come and go at runtime. That means the traditional wiring approach isn't suitable. In my project, we are using Spring Dynamic Modules, which somewhat combines the static nature of wiring with OSGi's dynamic capabilities.

The probably most important reason why my understanding of DI /IoC isn't working in our application, is the fact that we are trying to mix Spring's life-cycle and IoC capabilities with that of Eclipse. The Rich Application Platform has its own notion of wiring and if you base your application on it, you must comply with that. The way Eclipse wires its dependencies is similar to that of Spring, but not compatible after all.

Instead of having dependencies injected by Spring in a inversion of control way, we are basically left with the good old Service Locator.

The fundamental choice is between Service Locator and Dependency Injection...is about how that implementation is provided to the application class. With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.

Although there are solutions, bridging the gap between Eclipse and Spring, there's nothing supported "officially". That was the reason for us to go the Service Locator route, although to me it doesn't feel right. There are pros and cons when it comes to the Service Locator pattern. One of the most compelling arguments against it, is the hard reference to the locator instance in your code. It is a necessary evil in order to get a hold of your dependencies. This pain point was kind of mitigated for me, when I read that Netbeans is using it in their code base to lookup dependencies as well.

The solution we came up with, is a static ApplicationContext instance in the Activator class of each OSGi bundle. It serves as a location to grab the dependencies needed in the contained environment of a bundle. The ApplicationContext is configured using the usual Spring XML-configuration, together with Spring Dynamic Modules. An alternative approach, that we considered as well, is to use the OSGi API to locate your services. It limits the dependencies to Spring, since you don't need a reference to the ApplicationContext. If you are planning to replace Spring with anything else, you might consider taking that approach.

Although this works very well, it doesn't fit my understanding of DI and IoC. I want my dependencies to be injected, wherever I need them. I don't want to ask for them myself. Martin Fowler mentions in his article, that using the black magic of IoC, in contrast to the ServiceLocator pattern, makes your code harder to understand and debug. I can think of situation where it's harder to debug your code, but I cannot imagine how your code would be harder to grasp. I think, if you clearly state the dependencies of your class, it is easier to comprehend and to test. The fact that Spring does some magic and injects the dependencies for you, doesn't harm understandability at all.

Trying to get the best of both worlds - Eclipse RCP and Spring - probably means to compromise about doing DI using a Service Locator instead of doing DI with IoC. But isn't everything we do in software development a compromise?

Configuration Notations

I've been using XML as a configuration notation since I've started doing web development. It's a basic building block when it comes to Java EE. Unfortunately I think it's also one of the most common source of errors, especially because there's no compiler which tells you what's wrong. How many times have you deployed your web app in a Java EE container, only to find out, that you have a typo in your web.xml. One advantage of XML, in my opinion, is readability. If you have a configuration file, XML does a decent job in suggesting what you are actually trying to configure and how it relates to your code. I do admit that it can become very verbose very quickly, but using XML namespaces, like the Springframework, you can keep it under control - at least to a certain extend.

I'm currently working on a project which leverages the Springframework. We are using the container to manage dependencies, Dynamic Modules to leverage OSGi and a lot of other stuff which sometimes makes life easier. Spring's default configuration option is XML. So if you want the Spring container to know about your class you'd write something like the following:

<bean id="person" class="de.linsin.sample.spring.contracts.PersonImpl"/>

Of course that's not the whole story, there's lot's of namespace configuration and all the other XML stuff in your configuration file. Basically every class you want Spring to know about, needs a complement in your configuration. It quickly gets more and more, e.g. if you add transaction management or logging. In short: your XML configuration virtually outgrows!

I said this before, but here it is again: I like Spring's XML configuration and I believe it's all a question of proper tooling. If you have a tool like IntelliJ IDEA, it's a lot easier to handle your Spring configuration.

There's another configuration notation, which has been around for a while: properties files. They contain simple key value pairs:

authentication.factory=de.linsin.sample.factory.LDAPAuthFactory
admin.email=dlinsin@gmail.com

In my last project, we used properties files excessively to configure global variables, which are set at startup of the Java EE container for the lifetime of the JVM. Properties files are also the standard way of internationalizing your application. For each language you can provide a file which contains keys that are used throughout your application and values, containing the translated messages. The keys are being substituted at runtime with the appropriate values, depending on the currently chosen language. As with XML, there is no compiler warning or static check, which could tell you that you haven't configured your properties file correctly. It's generally a good idea to add a null check before accessing a property, since it can lead to nasty NPEs if it's undefined. In my opinion readability of properties files can't keep up with XML. Usually your files are sprinkled with comments, which indicate where and how the properties are used. That doesn't really scale and comments are not always the best way of enforcing a contract.

Another problem with properties files is encoding. As soon as they contain none Latin-1 characters, you need to do extra work more work to avoid problems. Usually you shouldn't have those encoding problems with XML. Proper tooling is a real problem when it comes to management of properties files. I haven't found a really good tool, which conducts some kind of check if my code and properties files are in-sync. I have to plug IntelliJ again here. They are doing a somewhat reasonable job of managing your properties.

One of the most exotic configuration notation, at least in my opinion, is JSON. Yes, I know! You are probably raising your eyebrows right now, like I did the first time I read about it. JSON is used as the configuration notation of SpringSource's Application Platform - S2AP. You can among other stuff configure logging using JSON:

"trace": {
"directory": "serviceability/trace",
"defaultLevel": "info",
"specificLevels": {
"com.foo.*" : "verbose",
"com.foo.UnimportantClass" : "info",
"com.bar.ImportantClass" : "verbose"
}
}

As probably most of you, I've used JSON only for web development. I think its most common application is calling server-side code from JavaScript. Using it for configuration is an interesting idea, though. When looking at the example above, I think the readability is quite reasonable. The hierarchical structure, similar to XML, makes it easy to figure out what you are trying to configure. There are frameworks out there, which are converting JSON to Java and vice versa, so there's no need to write a parser yourself. Like with the perviously mentioned notations, catching mistakes before deployment is rather limited, since there is no compilation step involved. As for tooling, every decent IDE supports JavaScript nowadays and most of the time that includes JSON. It shouldn't be a problem, getting some tool support when editing JSON snippets.

Comparing these different configuration notations rather subjectively, there is no clear winner for me. The only real difference is proliferation. Despite its somewhat bad reputation, XML is clearly the most widely used configuration notation, directly followed by properties files. JSON is kind of the "new kid on the block", because I've never seen it being used for configuration, before S2AP.

Besides its wide usage and ubiquity, XML has DTD and namespaces, which I believe can eliminate the two major downsides: verboseness and misconfiguration. The strong tool support, which came with the proliferation, can help to handle spelling errors and management of large numbers of XML files. I think working with XML can be quite painless today, if you have the right tools.

SpringOne08.exit();

The last 2 days I attended SpringOne08. It was even better than last year, although it was only 2 instead of 3 days. I met a couple of nice fellow developers and learned quite a bit about the Spring Framework.

I'm not gonna summarize any sessions here since you can already find blogs out there already covering a lot of sessions. I just like to point out, that there was one ubiquitos topic: OSGi. SpringSource is heavily backing OSGi, with Spring Dynamic Modules as well as their new product SpringSource Application Platform (S2AP). It's a topic you won't get passed if you are developing enterprise applications.

From a technical point of view I find this very interesting. I wonder how that will affect the application server market. I guess it's still early for predications, but you should definitely keep a close eye on S2AP.

SpringOne 2008 coming

SpringOne 2008 is coming next week and taking place in Antwerp, Belgium again. I was there last year and I can only recommend conferences held by the BeJug. They are usually well organized and you get the chance to talk to a lot of fellow developers.

I checked out the conference schedule and unlike last year, there is a lot more Spring stuff covered. All the sessions are packed with topics on the different parts of the Spring Portfolio. A lot of talks are covering OSGi and the recently announced Spring Application Platform. Those are exactly the topics I'm interested in, because we use some of them on my current project. Last year there were a lot of general sessions, e.g. Eric Evans was speaking on Domain Driven Design.

There is one thing, that never seems to change though: the sessions I'm interested in are always taking place at the exact same time.

OSGwhat...?

There have been a couple of times where the poll results on java.net were, let's say, rather surprising. Those numbers, however are scary, in particular the count of "OSGwhat". There has been JSR 291 and so much buzz about JSR 294 (hint: check the number of votes) and JSR 277, how can you not know what OSGi actually is?

JSR 294 Superpackages

In "The Open Road", which contains a series of blogs about the upcoming Java SE 7 release, Elliotte Rusty Harold wrote about JSR 294 aka superpackages.

Java's package mechanism today, is basically broken, because there is no hierarchical model. Hence, there is no way to completely hide your implementation from the outside world and no true separation of interfaces and implementation. One could argue that you could mark your methods "private" or "package private", but you will be running into situations - sooner or later - where you want them to be accessible not only within the same package, but also from subpackages of their hierarchy.

JSR 294 is trying to address this problem. The idea is to create a superpackage around a set of packages, which are called "members". Those members contain classes, so called "exports", which define access points to the superpackage from outside world. The most compelling advantage of this JSR, is fact that access to members are restricted by the compiler. You will get a compile time error, if you try to use classes of a superpackage, which are not exported. Unfortunately there is no way to restrict access to methods, which would come in handy.

Here is an example of a superpackage definition, which would reside in a file called super-package.java in "de/linsin/sample":

superpackage de.linsin.sample {
// contained in superpackage
member de.linsin.sample.p1
member de.linsin.sample.p2

// access points
export de.linsin.sample.p1.SampleClass
export de.linsin.sample.p2.SampleSingleton
}

The first thing that came to my mind when I saw this was OSGi. You can do the same things, using the OSGi Manifest headers:

Bundle-SymbolicName: tutorial.example2
Bundle-Version: 1.0.0
Bundle-Activator: tutorial.example2.Activator
Export-Package: tutorial.example2.service
Import-Package: org.osgi.framework

In addition to that, you can add a version or range of versions to imports and exports, to enforce the OSGi classloader to only give you that version or any version in that range.

Comparing OSGi to Java is not fair and I have to mention, that OSGi is much more powerful, than what I pointed out here. A better comparison would be Java to Scala:

package com.codecommit.mypackage.impl

class MyClass {
private[mypackage] def myMethod = "test"
}

The example was taken from Daniel Spiewak's tutorial on Scala.

Scala lets you denote classes and methods with an access modifier, which can either be an enclosing package or class. It enables true compile-time checked separation of interfaces and implementation with a very neat syntax.

I really like the idea of JSR 294, but in my opinion the implementation is rather unfortunate. If you look at the example in Elliotte Rusty Harold's article, which shows how to hide a method from the outside world, you get an idea of what I'm talking about. I don't want to create extra classes, in order to hide any methods.

However, JSR 294 is still in early draft review, so there is still time to fix the broken implementation.

OSGi @ JUG-Ka Follow up

You can also download the pdf version from the JUG-Ka Google Group.

OSGi @ JUG-Ka

The Java Users Group Karlsruhe is going to have an OSGi session tomorrow.

I'll start the event with an introductory to OSGi while my co worker Heiko will give some insights on Spring Dynamic Modules. Michael Grammling will conclude the talk with on overview of the best practices and give some information on the activities of the OSGi Alliance.

If you haven't heard of OSGi yet, you definitely should come. It's a hot topic in the Java world right now and I think it's here to stay. If you already know about OSGi, you are ver welcome to contribute to the (hopefully) lively discussions.

Back from SpringOne

The last 3 days I spent in Antwerp, Belgium attending SpringOne 2007. It was a great conference, all about Java and the Spring Framework. I added a lot of new stuff to my list of things I wanna check out like, Coherence, BEA's WebLogic 10 and Compass as well as Spring Batch, OSGi and SCA.

At the moment I'm working on a summary of the conference for the Java User Group Karlsruhe, which I'll probably post here too. Until then, some impressions of the conference: