How to package and consume an existing Java library with OSGI

Question

After asking for help for managing dependencies on different versions of the same libraries in Java, it was suggested that I should take a look at OSGI implementations. Being under a deadline pressure, I could really use some help that would save me from digging through endless OSGI docs. I have a working app, which is going to use a new framework. The framework uses different versions of jars that I'm already using, so I want to package the new framework as an OSGI bundle. Can I leave my app as it is, and use the OSGI bundle only as a container within JVM? This would mean I would be using OSGI bundle only to isolate a set of classes from the rest of the JVM to avoid conflicts between different versions of classes. in other words, I want to use OSGI without carrying all my code to an OSGI based setup.

Kind regards Seref

Answer 1

I do not have a complete answer for you here, I just wanted to counter what deterb said:

First, you have to have your entire application within the OSGi framework.

That is not true. Another approach would be to embed an OSGi container into a host application.

The tricky part here is the interaction between inside of OSGi and outside, because the code lives on separate classloaders.

You can make your host classes visible to the OSGi part using the OSGi system classpath. The other way around is more difficult.

One way for host code to interact with bundles is an interface that is visible to both the host application and the bundle, i.e. part of the host. Another way would be to use reflection.

If you have a clear separation between host and OSGi, for example a plugin system, then this could work quite well.

Being under a deadline pressure

That could be a problem. There is a lot to learn with OSGi, and since it is just about to hit the mainstream, there is still a lack of community knowledge, tool support, library compatibility, and so on.

The biggest question you should ask at that point is: Do I really need to manage different versions of dependencies at runtime? If not, i.e. you can figure things out at the time of deployment (for example by configuration), then there may be a simpler solution for you.