Including additional resources with OSGi bundles

Question

I'm working on an OSGi bundle which implements a service as a wrapper around a native executable. That is, the service runs the executable with ProcessBuilder, feeds it some data, and retrieves the result. My question is about the best way to package this bundle. The native executable includes a number of dependent data files which all must be present on disk for the tool to run. I've found plenty of references on dealing with native DLLs in OSGi, but none that address files associated with a bundle that must be present on disk rather than just retrievable through the classpath.

I was thinking that I could include the exectuable and dependent files directly in the bundle archive and then programmatically extract to some directory when the bundle is started. The other option I can think of is to put the executable somewhere and set a system property that points to it or something, but I want to keep configuration to a minimum.

A solution that isn't specific to a particular OSGi implementation would be nice, but if not, I'm using Equinox.

Thanks!

Answer 1

Do these additional files need to be writeable by the native code? If not, there's nothing stopping you putting any files you like inside a bundle.

The usual problem you have in OSGi is working out the path to the file as OSGi does not assume a file system is available (it's not as strange as it sounds as OSGi started out in embedded devices).

How do you control where the native code looks for its related files? Do you need to pass it a path?

If you want a directory to copy or unpack stuff, then use:

org.eclipse.core.runtime.Platform.getStateLocation()

Which gives you the working directory for the bundle.

If you want to find the path for a particular file in your bundle, you can do:

org.eclipse.core.runtime.FileLocator.toFileURL((context.getBundle().getEntry("/etc/readme.txt")))

Which, in this case, will return an file URL to the /etc/readme.txt in the current bundle.

Both pieces of code assume they are inside the activator's start() method.

Answer 2

Your solution works, of course. But you have to be careful to also stop and remove any resource that you extracted and started during the installation. This might especially difficult to track in case an executable also created any kind of working files.

You should do this because one of OSGi's strength is the lifecycle management, which allows you to also remove bundles and services without a trace. For this, the framework tracks everything a bundle does. If you keep an execuable running after you removed the bundle that installed and started it, the connection is lost and it may keep running until the machine is rebooted (often not an option for embedded systems).