This week's book giveaway is in the Server-Side JavaScript and NodeJS forum.
We're giving away four copies of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques and have Mario Casciaro & Luciano Mammino on-line!
See this thread for details.
Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!

Paul VanderLei

+ Follow
since Apr 12, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paul VanderLei

I had that problem before also. I noticed that it happened when my Eclipse window was on an external monitor, but never when it was on the primary screen. Maximizing the editor also forced it to update the markings.

This problem also went away permanently as soon as I got on the Helios release of Eclipse.
Neil Bartlett makes my favorite analogy on his blog (

A Strained Shopping Analogy

This point about imports is very important, so I will digress for a moment into a hopefully humourous, if somewhat exaggerated, analogy about shopping.

My wife and I have different approaches to shopping. I regard it as an onerous chore. When I must purchase something, I find a shop (or group of shops) that sells the items I need and I buy just those items and take them home. I don’t care which shop(s) I visit so long as I get the items I need.

In contrast, my wife goes to a shop she likes and basically buys everything in that shop.

Obviously I believe my approach is superior, because my wife has no control over what she brings home. If her favourite shop du jour changes its inventory then she ends up with different stuff… certainly lots of stuff she doesn’t need and perhaps missing some of the stuff she really does need.

It gets even worse… sometimes she ends up with an item that will not work on its own, because it has a dependency on something else, like batteries perhaps. So she has to go shopping again for batteries, and of course ends up buying the entire contents of the battery shop. Straining the analogy a little now, we could imagine that something else acquired from the battery shop also depends on something else, so she makes yet another trip to another shop, and another, purely to satisfy the requirements of a bunch of items that were not even needed to begin with! This problem is known as “fan-out”.

Hopefully the analogy with a module system is clear. The pathological shopping behaviour is equivalent to a system that forces us to import everything from the modules we declare a dependency on. When importing, we should import what we actually need to use, irrespective of where it comes from and ignoring all the things that happen to be packaged alongside it. We see the fan-out problem acutely when using the Maven build tool, which supports only whole-module (i.e. “buying-the-whole-shop”) dependencies, and as a result must download the entire Internet before it can compile a 200-byte source file.

To summarize, Require-Bundle is how Neil's wife shops. Import-Package is how Neil shops. My advice: shop like Neil.
From Chapter 5 of the book:

Favor Import-Package over Require-Bundle

The manifest headers Import-Package and Require-Bundle are used to describe
a bundle’s dependencies.

Import-Package—This header is used to express a bundle’s dependency upon packages that are exported by other bundles. At runtime the framework analyzes the constraints and wires the bundles together.

Require-Bundle—This header is used to express a bundle’s explicit dependency upon other bundles by specifying a list of bundle symbolic names. A bundle that uses this header automatically has access to the packages exported by its required bundles.

Importing packages is recommended over requiring bundles as it results in a more flexible and loosely coupled system, offering system designers the ability to swap out implementations and deployments of function to suit their needs.

When I look back to ten years ago when OSGi was very new and think about how we prepared for the future (we now call it the present!), here's what comes to mind: We didn't bet our farm on some newfangled framework called OSGi. But we did bet that making our applications modular and relying on a clean separation between our business logic and our dependency injection details was a good idea. This meant that as OSGi evolved, porting our applications was pretty easy. If OSGi had withered up and died, we could have moved our well-structured application to some other more successful framework, or we could have rolled our own.

I thin the same holds true now as we contemplate the next ten years. Don't bet your farm on OSGi. Bet it on well-structured, highly modular, and decoupled architecture. Then OSGi (or Jigsaw or SpringDM or whatever) becomes more of a deployment detail. I write code all day long that runs on OSGi. But I spend a very very tiny portion of my time actually being concerned with OSGi per se.
"I was a bit puzzled why the tests are using EasyMock with Java 5 and JUnit 4."

I think you're asking why, since the Toast application is implemented with Java 1.4, would we suddenly jump to Java 5 to do the testing.

We use Java 1.4 in a lot of real-world embedded applications because the VM and JRE are considerably smaller than Java 5. So it's a purely runtime constraint. At development time, there's no such restriction. EasyMock requires at least Java 5, so we just use Java 5 to run our tests. But our application is compiled against the Java 1.4 target so we know it will run on a Java 1.4 VM and JRE when we deploy it to the field.
11 years ago
OUr book does not discuss blueprint container. Maybe Jeff can add some pointers regarding that topic. That said, I think you'll find that the concepts in using OSGi are surprisingly portable across different container frameworks. And our book certainly covers a lot of best practice grounds for modularity, etc.
I've been using OSGi in production for over ten years.
Thanks for the question, Anil.
Naturally, we'd like to think we cover beginners, intermediates and experts all! But I think we work best for folks who already have a solid understanding of Java. Our application tutorial walks thru the actual doing of development, so it's good for those who are new to OSGi and to the tooling, since we introduce the concepts along the way. We also have a deep dives and a reference section of the book which is more targeted toward the expert or the expertly curious. At the end of the day, we are pragmatists first and theoreticians second, so I think the book will resonate with those who are interested in actually doing OSGi as opposed to those who just wanna think about it.
You're right. It is tough to compete. I think that hacking away without OSGi can seem quicker in the short term. And a shortsighted customer will fall for that. But I think OSGi helps you in terms of testability, modularity, maintainability, reusability and dynamic updating. I'm sure others could add to this list.
I'm not sure I understand your question here. Eclipse plugins are OSGi bundles. And Equinox's implementation ships as OSGi bundles, which, in turn are plugins.

Karthik Shiraly wrote:Hi Jeff, Paul and Simon,

About OSGi integration best practices:
Every example I've seen on OSGi involves a call to OSGi API for looking up a service. But I see it as a deployment aspect (a side concern) and I feel an application should not include any kind of direct interaction with OSGi, except to be aware that there may be temporary unavailability of certain services. I feel it's better for OSGi to be used external to the application - more like an installer and internet aware updater.
Is there any framework / tool / approach to integrate OSGi in this manner? Does Equinox help in any way here?

Thanks for your time,

Karthik, you have hit the nail on the head here. We say over and over in our book (as well as our training and our conference presentations) that if you are calling OSGi APIs in your application code, then you are doing it wrong. We recommend using Declarative Services to isolate the bundle dependency and lifecycle concerns. This helps simplify deployment, it aids in testability, and it even makes it easier to deploy your application on non-OSGi dependency injection frameworks or with no framework at all. So to answer your question: Yes. Use Declarative Services.
Josh, first of all, your experiences are actually the norm, in my experience. Moving to SOGi is not easy if the legacy application has not paid proper attention to modularity. I recently read a great blog-rant about this very topic:

Your specific question about how to deal with non-OSGi code is addressed at length in our book. Chapter 22 presents 4 different approaches to bundling a JAR: Bundling by Injection, Bundling by Wrapping, Bundling by Reference, and Bundling using bnd.

The bottom line is that it's never simple. BUt if code is modularized ahead of time, it's much easier to move to OSGi.
Great question, Ernst. I certainly have been through this kind of frustration in the past.

First off, bear in mind that OSGi per se is not the culprit here. It will depend entirely on which implementation you are using. From your question, and given our book is about the Equinox implementation, I'll assume that.

With regard to the book, we do have a decent size section on troubleshooting, including the classic ClassNotFoundException. But in my personal experience, these kinds of problems can be mitigated by holding to a few core practices:
1. Use DeclarativeServices. If you're coding to OSGi APIs right in your application code, you're doing it wrong. Isolating the bundle lifecycle issues to DS helps a lot.
2. Always use equinox.ds.print=true. It will provide more information when erros do occur.
3. Try to work in small increments. If you try to get a massive bundle ecosystem up in one big bang, the troubles will be too tricky to diagnose. Start small, and grow your implementation a bit at a time, and when there are problems, you'll understand better where to look.

Aetius Flavius wrote:Hi,

Can OSGi be applied to J2EE web applications for example to seperate the concerns of business rules and presentation?


Yes, Matt, it certainly can. While our book's example focuses on a smaller client application, we do have a large section about server-side OSGi.