Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

[TSE] Spring-OSGI with Adrian Colyer

Adrian has CTO as his title on his slides. Wasn't he hired as "Chief Scientist" originally? I wonder why his title changed? Maybe having the CTO title is a better way of getting more cash when the buyout happens? What buyout you ask? I don't know, but I can't help but think that Interface21 is on the radar of major organizations like Oracle and BEA. While it might suck for those guys to answer to a larger organization, it would be nice to see Rod, Juergen, et. al. benefit ($$) from all their hard work.


  • What is OSGi?
  • What problems does it help us to solve?
  • How does it work?
  • Where does Spring fit in?
  • Spring-OSGi

One of the first questions people ask about OSGi is "what the heck is it?"

The 2nd question is "what's with the lowercase i?" Seriously - does anyone know?

Most people don't even know what it is. OSGi stands for Open Services Gateway initiative. From the very beginning, it was designed to be lightweight and dynamic. This is the major difference between it and other containers. It's always been designed to have things added and removed. Now it's tagline is: "The Dynamic Module System for Java".

It's designed to allow you to partition a system into a number of modules (a.k.a. bundles). There's strict visibility rules (similar to protected and private). There's a resolution process (dependencies are satisfied) and it understands versioning.

It's dynamic! Modules can be installed, started, stopped, uninstalled and updated - all at runtime.

It's even service oriented (no wonder IBM loves it). Bundles can publish services (dynamically). The Service Registry allows other bundles to find services and bind to them. Services come and go at runtime, all taken care of for you.

Where does OSGi come from? It's backed by the OSGi Alliance. Unfortunately, this site makes it difficult to figure out exactly what OSGi is. The founders of OSGi understood it needed to be lightweight and dynamic from day one. It started in 1999, and was originally focues on embedded Java nd networked devices. In 2003 it was exteneded to support to mobile devices. In 2004, it had significant ope source community opttion with Eclipse. In 2006 and 2007, it's moving into server-side Java.

Who's doing OSGi containers?

  • Open-source implementations: Equinox, Felix (Apache), Knopflerfish
  • Significant Enterprise usage: Eclipse, IBM (WebSphere, Lotus), JOnAS, interest from BEA and Oracle

So what? What problems does OSGi solve?

Visibility By default, a bundle is a black box. It's completely protected and you can't see inside it, not even with reflection or any other classloading trickery. Only exported packages are visible outside of the exporting bundle. This stops unintended coupling between modules, enables independent development, faster development cycles and security.

Operational Control
An OSGi container allows you to see all modules and their status - using the OSGi console or JMX. You can get information on wiring, install new bundles, activate bundles (and publish services), deactivate bundles (and unregister services), refresh bundles, stop bundles and uninstall bundles. The beauty? You can do all of this without stopping or restarting the application!

What is an OSGi bundle?
It's just a jar file. There's no complicated tools or sophisticated packaging required. All you need is a symbolic name in your META-INF/MANIFEST.MF file. For example:

Bundle-SymbolicName: org.swf.beans

There are a number of other attributes you can specify, but the SymbolicName is the only required one.

There's a Maven OSGi Plugin. The major change from a regular JAR project is <packaging>jar</packaging> -> <packaging>osgi-bundle</packaging>.

Sidenote: You have to love how Maven is so Google un-friendly. Searching for Maven OSGi Plugin doesn't seem to provide a definitive answer to the Maven plugin that Adrian is talking about. I'm guessing Maven has OSGi support natively?

Eclipse has fantastic tooling support for OSGi via "plug-ins". You can create a new "plug-in project" and use Eclipse to create/edit your OSGi manifest. Eclipse calls bundles "plug-ins" - so creating a plug-in project is the same thing as creating a new bundle.

Export-Package is a header (a.k.a. manifest entry) used to export types for other bundles to use. If it's not exported, it's not visible. For example:


You can also specify a version by adding a semicolon after the package and specifying "version=#". For example:

Export-Package:; version=1.0, 
      ; version=1.0, 
      ; version=1.0

In addition to specifying specific versions, there's syntax to control a specific versions. For the examples above, OSGi will actually get any version 1.0 and above.

For the next 10 minutes, Adrian talked about how class-loading and resolution works. He also pointed out how to bootstrap a bundle (using the BundleActivator interface) and the basics of the Service Registry. The BundleContext allows you to get and remove services.

What about JSR 277 (Java Module System)? It's a very crude version of OSGi with its "RequireBundle" mechanism. The key problem is the lack of dynamics (loading/unloading of modules). Peter Kriens (of the OSGi Alliance) shares his thoughts on this in his JSR 277 Review. JSR 291 (Dynamic Component Support for Java SE) may kill 277 because it relies on OSGi. Its goal:

Establish a JCP specification for a dynamic component framework supporting existing Java SE environments based on the OSGi dynamic component model specifications. "

What about Spring?
OSGi offers an excellent foundation for building enterprise applications. How can you exploit the power and sophistication of OSGi w/o adding complexity? How can you split your application into a number of OSGi bundles? Between bundles, you need an easy way to expose bundles as services and wire service references b/w them. What about testing? How can you test bundles w/o running them inside an OSGi container?

Spring-OSGi hopes to allow you to build on OSGi, but deploy in Tomcat, WebSphere, WebLogic or any other application server. Basically, it gives you an "OSGi powered Web Application".

Project Goals: Bring the benefits of OSGi to enterprise applications and use Spring to configure modules/bundles. In addition, make it easy to code your applications w/o depending on OSGi APIs and make it easy to unit and integration test.

Project Collaborators: Adrian is the lead, and there's active committers from BEA and Oracle. Input to the project's specification has been gathered from OSGi Alliance (technical director and CTO), BEA, Oracle, IBM, Eclipse Equinox, Felix and many individuals.

Spring modules (spring-core, spring-beans, spring-aop) will be shipped as OSGi bundles in Spring 2.1. All the necessary import and export package headers will be pre-defined. This will enable an OSGi application to import and use Spring packages and services.

OsgiBundleXmlApplicationContext is a Spring application context based on an OSGi bundle. It uses the bundle context and classloader to load resources and implements Spring's resource abstraction for OSGi. There is a "bundle:" prefix for specifying an explicit path.

To do integration testing with Spring-OSGi, you can extend ConfigurableBundleCreatorTests. This automatically creates an OSGi bundle containing the tests on the fly. This class handles starting an OSGi container, installs all bundles and runs tests inside OSGi. Currently, it supports Equinox, Felix and Knopflerfish. If you're using Maven, it's simple to switch containers with profiles (i.e. -Pfelix). Adrian did a demo in Eclipse. I didn't seem the OSGi container starting (or him specify which one to use) but the test seemed to finish rather quickly.

To interact with OSGi, there are a number of conveniences that Spring-OSGi provides: BundleContextAware, <osgi:property-placeholder>, <osgi:bundle> (starts other bundles), <osgi:virtual-bundle> (bundle created on the fly).

OSGi-based web applications
It's entirely possible to run an OSGi container embedded in another container. Remember it's lightweight enough to run in a phone! Even OSGi in OSGi is supported.

Equinox is the only OSGi container that currently supports web applications. It uses a "bridge servlet" that acts as a front controller and dispatches servlet requests to bundles. To package your application as and deploy it to Equinox, you basically have to create a WAR with the bridge servlet as the only entry in web.xml and the only JAR in WEB-INF/lib is servletbridge.jar. Everything else is packaged under /WEB-INF/eclipse. Here's what that looks like:


Adrian did a demo showing a simple "Hello World" example deployed into an OSGi container. The output from the demo in the browser wasn't much. However, he showed how you could use an OSGi Console to interact (start/stop/refresh) all the different bundles. The fact that you can do this all at runtime has some pretty interesting implications.

My Thoughts
The demo makes Servlet/EJB containers look somewhat primitive. Will OSGi containers be the next generation of application servers? It seems somewhat likely, but as Adrian said, most of this stuff is on the bleeding edge (or even "razors edge" to quote Adrian). My guess is OSGi will be a very interesting space in 2007. However, I don't see myself deploying WARs to OSGi containers anytime soon. Maybe in 2008.

Can OSGi power a web application's plugin architecture? It doesn't seem like it. The web application would have to be deployed in an OSGi container to make this possible. Either that, or the web application would have to be an OSGi container itself.

Posted in Java at Dec 09 2006, 02:29:58 PM MST 6 Comments

WebSphere 6.1 supports this, I think. We're running on 6.0 and the developers are hoping to upgrade 0.1 of a version. OSGI would be a real big step forward for large applications. Hopefully, this can be deployed in the next few months :)

Posted by Solomon on December 10, 2006 at 01:20 AM MST #

[Trackback] What is OSGi? OSGi stands for Open Services Gateway initiative. ? ?? ?? ??? ??? "The Dynamic Module(Bundle) System for Java"??? ?? ??- ??? ? ???? ?? ?????- visibility rules? ?? ??.(??? private/public? ???)- a resolution process(??? ??? ??)? ??- ?? ??? ...

Posted by Younghoe.Info on December 10, 2006 at 02:38 AM MST #

As per your last paragraph "Can OSGi power a web application's plugin architecture?"

At Cocoon we've made some good progress in doing exactly this (initial RT and implementation).

For a more up to date status (as you say it's quite bleeding edge) feel free to poke around cocoon-dev.

Posted by Jorg Heymans on December 12, 2006 at 12:40 PM MST #

Maven is definitely the way to go for Apache Felix OSGi... and now if you do a google search on Mavin OSGi plugin, you get a reference to the maven-osgi-plugin in the Apache Felix page. Of course, I'm just biased toward Apache projects, since they are all of very high quality in my opinion.

Posted by Garrett Headley on October 19, 2007 at 12:25 AM MDT #

> The 2nd question is "what's with the lowercase i?" Seriously - does anyone know?

This is a funny story! :)

OSGi originates from the car industry. One of the companies that was heavily involved in the specification was BMW. That is where the lowercase 'i' comes from. All the BMW cars that have fuel-injection are named with a lowercase 'i' at the end. For example "BMW 760Li", or "BMW 328i".

For some reason the engineers working on the then called 'OSGI' spec started to call it 'OSGi'... and it sticked.

Posted by yoR on May 29, 2008 at 10:32 PM MDT #

Hmm, today OSGi is just a name. I like the BMW story but BMW became a member long after the name was devised. The i is just there for logo reasons, mixing upper and lower case creates a nice visual effect. The injection story might have played a role, it is not just BMW that uses the i for injection. Today we can call it Only Services Get injected. Hey! Now you can see how far ahead we were in 1999, not only did we predict SOA 8 years ahead of time, we also knew about Dependency Injection before it was called like that ! :-)

Just kidding, somebody started to use the lower case 'i' and it stuck.

Kind regards,

Peter Kriens

Posted by Peter Kriens on May 30, 2008 at 07:53 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed