Read the Spotlight Archives

Replies: 16 - Pages: 2 [ 1 2 | Next ]

Threads: [ Previous | Next ]

ClReply

Getting Started with OSGi: Dependencies between

Bundles
At 5:25 PM on Feb 12, 2007, Neil Bartlett Javalobby Regulars wrote:

In our previous tutorial installments, we looked at how bundles can be started and stopped, and how they can
interact with the framework and each other's lifecycle. But what are bundles really for?

Bundles are modules. They allow us to split apart our monolithic projects into manageable pieces which can
be loaded individually into an OSGi runtime. The problem is, whether we like it or not, modules nearly
always have dependencies on other modules. In plain old Jar files, there was never a reliable way to specify
the dependencies on other Jars (no, the Class-Path entry in the manifest was not a reliable way of doing
this). Therefore you never really knew for sure if the code in a Jar would work, or would throw
ClassNotFoundException s at runtime.

OSGi fixed this problem very elegantly. But it's better to show you than tell you... so let's hurry up and get to
the code. Unfortunately up until now we have been using the default package, but this won't work any more;
we will need to start working with proper packages. So lets start off with a very simple JavaBean-style class,
which you should copy into the file osgitut/movies/Movie.java :

package osgitut.movies;

public class Movie {

private final String title;
private final String director;

public Movie(String title, String director) {

this.title = title; this.director = director;
}
public String getTitle() { return title; }
public String getDirector() { return director; }
}

Now we will create an interface in the same package. Create the file osgitut/movies/MovieFinder.java and
copy in:

package osgitut.movies;

public interface MovieFinder {

Movie[] findAll();
}

Now lets get these two classes into a bundle. Yes, our bundle will be ridiculously small and almost useless,
but that's okay for now. As before we need to create a manifest file, so open up MoviesInterface.mf and
copy in the following:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Movies Interface
Bundle-SymbolicName: MoviesInterface
Bundle-Version: 1.0.0
Export-Package: osgitut.movies;version="1.0.0"

There's a new line in here that we haven't seen before: Export-Package . This simply says that the package
osgitut.movies is exported from the bundle. This may seem a little odd at first, because in plain old Java
Jars, everything is exported. But haven't you ever wanted to put some code in a package which was only
visible internally withing your Jar? Sure, you can make some classes private or protected, but then they're not
visible to other packages within your Jar. So OSGi effectively has introduced a new code protection level: if
a package in your bundle is not listed on the Export-Package header, then it is only accessible within your
module.

You'll also notice that we attached a version number to the package. This is important as we will see later. It's
not absolutely necessary to supply a version, by the way, but if you don't then OSGi will automatically assign
the version "0.0.0" to your package. I think it's good practice to always add a version explicitly.

Now let's build this bundle:

> javac osgitut/movies/Movie.java osgitut/movies/MovieFinder.java

> jar -cfm MoviesInterface.jar MoviesInterface.mf osgitut/movies/*.class

We're not going to go right ahead and install that bundle into the runtime. First we're going to build another
bundle that depends on it. We want to create a concrete implementation of the MovieFinder interface, so
copy the following into osgitut/movies/impl/BasicMovieFinderImpl.java :

package osgitut.movies.impl;

import osgitut.movies.*;

public class BasicMovieFinderImpl implements MovieFinder {

private static final Movie[] MOVIES = new Movie[] {
new Movie("The Godfather", "Francis Ford Coppola"),
new Movie("Spirited Away", "Hayao Miyazaki")
};

public Movie[] findAll() { return MOVIES; }

}

Now we need a manifest file, so create BasicMovieFinder.mf :

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Basic Movie Finder
Bundle-SymbolicName: BasicMovieFinder
Bundle-Version: 1.0.0
Import-Package: osgitut.movies;version="[1.0.0,2.0.0)"

Notice that we are importing the package osgitut.movies which was exported by the other bundle. We have
also this time added a version range on the import. The framework uses the range at runtime to match up the
import with an appropriate export. OSGi uses a syntax for version ranges that will be familiar to most
mathematicias: the square bracket means "inclusive" and the round bracket means "exclusive". Effectively
we have specified the version "1.x".

Again, adding the version constraint on the import wasn't particularly necessary in this case, it's just a good
habit to adopt.

Now lets compile and build our second bundle of the day as follows:

> javac -classpath MoviesInterface.jar osgitut/movies/impl/BasicMovieFinderImpl.java

> jar -cfm BasicMovieFinder.jar BasicMovieFinder.mf osgitut/movies/impl/*.class

Finally we're ready to try these bundles out in Equinox. I'm not going to give full instructions this time, as I
think you should be getting the hang of it. Firstly install the BasicMovieFinder bundle, and run ss . You will
find that the bundle is in INSTALLED state:

id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 INSTALLED BasicMovieFinder_1.0.0

(NB your bundle list may be starting to look a little different from mine, in particular the bundle ID will
depend on how many times you installed and uninstalled the HelloWorld bundle from last time. You'll have
to mentally translate the bundle IDs that follow).

INSTALLED just means that framework has got the bundle, but has not yet resolved its dependencies. One way
to try to force Equinox to resolve our bundle is with the refresh command. So type refresh 4 and then ss
and you should see this:

id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 INSTALLED BasicMovieFinder_1.0.0

The bundle still isn't resolved! Of course, we need to install the "interface" bundle which contains the Movie
class and the MovieFinder interface. To confirm that this is the problem, type diag 4 to get diagnostic
information:

file:BasicMovieFinder.jar [4]
Missing imported package osgitut.movies_[1.0.0,2.0.0).

Yes, that was the problem: we can't import the package osgitut.movies because no bundle is currently
exporting it. So now install the MoviesInterface.jar bundle and run ss . The listing will look like this:

id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 INSTALLED BasicMovieFinder_1.0.0
5 INSTALLED MoviesInterface_1.0.0
The final step is to ask Equinox to try again to resolve the BasicMovieFinder bundle, by running refresh 4 .
The output from ss will now show:

id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 RESOLVED BasicMovieFinder_1.0.0
5 RESOLVED MoviesInterface_1.0.0

The BasicMovieFinder bundle is now RESOLVED ! This is an essential step, because until the bundle is
RESOLVED it cannot be started, and it cannot supply dependencies to any other bundle.

Note that usually it's not necessary to do manual resolution like this. Normally bundles are automatically
resolved when they are needed -- for example, notice that the MoviesInterface bundle is now RESOLVED even
though we didn't explicitly refresh it.

That's it for now. For more fun things you can do with the Equinox console, take a look at Chris Aniszczyk's
excellent article on IBM developerWorks . Stay tuned for the next installment, where we start to delve into
OSGi services.

16 replies so far ( R Post your own) Click Here!

ClReply
1. At 6:06 PM on Feb 12, 2007, Benoit Xhenseval
Javalobby Newcomers wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Hi Neil

Thanks for this, it is very interesting but I am not going to hide that the level of details and the steps
required are quite daunting. Although I can see some advantages in doing this, I cannot see myself
doing it manually for any large project (where it probably would be the most useful!) Is there any tool
that can do all this?

As far as I can see OSGi is all about finding the "right" level of granularity... Will you discuss a few
rules of thumb at some point?

Thanks for the series of articles,

Benoit
ClReply
2. At 6:38 PM on Feb 12, 2007, Neil Bartlett Javalobby Regulars wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Thanks Benoit,

You're right, as you start to scale up, these files and so on are unmanageable if you stick to just a text
editor and javac . Remember though that those tools are inadequate for any significant Java project,
not just an OSGi one. For example, there's a lot that we could do to make the above post simpler just
by using ANT. However the focus of the tutorial series is to show that there is no "magic" involved.

Regarding your question about tools... there's an obscure Java IDE I've heard of called Eclipse.... but if
that's not your cup of tea then you can also look at the OSGi plugin for Maven, and/or the bnd tool
developed by Peter Kriens. This area is ripe for sophisticated tooling, and I hope we'll see some
 coming out of one of the Eclipse projects soon.

You're absolutely right about granularity. Getting that right is critical, and I think people are only just
starting to learn about what happens when an OSGi system starts to get REALLY big.

Regards
Neil
ClReply
3. At 6:49 PM on Feb 12, 2007, Chris Aniszczyk DeveloperZone Top 100 wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

The link to my article is slightly off, try this out :)

http://www-128.ibm.com/developerworks/opensource/library/os-ecl-osgiconsole/

I just notice an error in it by using System.out's instead of the CommandInterpreter's println's, pooo!
I'll have to fix that ;)
ClReply
4. At 6:59 PM on Feb 12, 2007, Neil Bartlett Javalobby Regulars wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Sorry Chris! Now, if only EclipseZone let authors edit their own posts...
ClReply
5. At 6:10 AM on Feb 13, 2007, Stefan Langer DeveloperZone Top 100 wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Great series.

I have a question which is slightly off topic but none the less you might be able to answer it.

Since every Eclipse-Plugin is a OSGI Bundle I wonder how I can obtain a bundle from OSGI Runtime
and make a Plugin out of it?
Something along these lines
// Not sure which object gives you the getBundle method since
// I'm typing this from memory
Bundle bundle = Platform.getBundle("id.to.bundle");
// this will fail with a ClassCastException
PluginA a = (PluginA)bundle;

Is this at all possible?

Regards
Stefan
ClReply
6. At 6:38 AM on Feb 13, 2007, Alex Blewitt DeveloperZone Top 100 wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Nah, you have to wait for one of the lackeys to do it for you.

I've corrected the link.

Alex.
 ClReply
7. At 6:39 AM on Feb 13, 2007, Neil Bartlett Javalobby Regulars wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Hi Stefan,

I'm not sure how you can "make a plug-in" out of a bundle. As you note, a bundle already IS a plug-in.
The term "plug-in" is simply legacy terminology from pre-3.0 versions of Eclipse.

As for your code, I don't know how to fix it because I don't know what the "PluginA" class is. There is
no class called "PluginA" in either the OSGi APIs or in Eclipse/Equinox.

If you call BundleContext.getBundle(long id) then you will get an org.osgi.framework.Bundle

object. That's an interface, and the concrete implementation will be an internal class from Equinox.
Why do you want to cast it to something else?

Regards,
Neil
ClReply
8. At 8:44 AM on Feb 13, 2007, Jesper Javalobby Newcomers wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Benoit,

Eclipse 3.2 already has some support for creating OSGi bundles and editing the manifest file,
managing dependencies etc. in a more user-friendly way.

In Eclipse, select New / Project / Plug-in Project. Now in the first step of the wizard, in the bottom of
the dialog, you can choose a target platform. Choose "an OSGi framework" there.

After following the rest of the wizard, you have an OSGi bundle project. You can edit the manifest file
with the user-friendly (Eclipse Forms-based) editor. On the second tab page of the editor you can
manage dependencies, and even automatically find dependencies.

To run the OSGi platform from inside Eclipse, choose Run / Run... and make a new run configuration.
In the tree on the left side choose "Equinox OSGi Framework".

When you start that run configuration, you will see the OSGi console in a console window inside your
Eclipse IDE, with your bundle deployed. You can type in commands in the console inside the IDE.
ClReply
9. At 9:07 AM on Feb 13, 2007, Alex Blewitt DeveloperZone Top 100 wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

I believe that he's looking at getting the Plugin subclass, which is the Bundle Activator for that given
bundle.

The way you'd get hold of it is to load the class defined by:

Bundle bundle = context.getBundle(id);

String className = bundle.getHeaders().get("Bundle-Activator");
Class clazz = bundle.loadClass(className);
 Depending on what you want to do (or how you achieve it) you can then use that class to do what you
want. For example, if your plug-in is a singleton (i.e. caches an instance in a static field) then using
reflection will do the trick to pull that value out might be what you need to do.

Does that answer the question?

Alex.
ClReply
10. At 9:38 AM on Feb 13, 2007, Chris Aniszczyk DeveloperZone Top 100 wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Note that in 3.3, we now support pluggable OSGi frameworks in PDE so you don't only have to run on
Equinox.
ClReply
11. At 10:05 AM on Feb 13, 2007, Neil Bartlett Javalobby Regulars wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Thanks Alex, however I hope you agree that's a very, very nasty hack! Whatever Stefan is ultimately
trying to do, there has to be a better and more reliable way than this.

Neil
ClReply
12. At 10:58 AM on Feb 13, 2007, Stefan Langer DeveloperZone Top 100 wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Actually my intention has more of a educational purpose then a practical one.
The idea was to get rid of the getDefault method in the Plugin Class. So instead of doing
PluginA.getDefault().doSomething()

I'd use
Bundle bundle = BundleContext.getBundle("PluginA.id");
// do something to the bundle to get PluginA Class
pluginA.doSomething();

but seeing that this is a hack (I thought there would be some simple cast involved ;) ) I'd go with the
first code snippet or use an extension point or OSGI Service to achieve dynamic behavior.
ClReply
13. At 11:48 AM on Feb 13, 2007, Alex Blewitt DeveloperZone Top 100 wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

So whilst you can get classes, you can't get instances :-) In fact, the plugin registry uses instances
cached in (effectively) a map which is then queried, keyed on the plug-in id.

If you were getting rid of the singleton hack (as you were proposing) then this approach would become
invalid anyway :-)

Either an extension poitn or an OSGi service is the right way to share an instance.

Alex.
ClReply
14. At 11:08 PM on Feb 13, 2007, yaohuang Javalobby Newcomers wrote:

Re: Getting Started with OSGi: Dependencies between Bundles

Neil, Thanks for your tutorial.

I am eager to learn your next tutorial on OSGi services, because I

was stuck in OSGi service in these days.

I have posted a question that OSGi service bundle state can not change from Resolved to Active on
Equinox forum, but no response. (http://www.eclipsezone.com/eclipse/forums/t90542.html). Could
you have a look at it?

Yao

Replies: 16 - Pages: 2 [ 1 2 | Next ] Threads: [ Previous | Next ]

thre
N P N N N U H R
Get Firefox! Powered by Jive Software Powered by Caucho Resin!
Eclipse(TM) is a registered trademark of the Eclipse Foundation