Summary of the problem: I have a simple Java ‘library’ which wishes to use OSGi internally to load and use plug-ins. That library has an API which may be used by any number of driver ‘applications’, from a simple command-line tool up to arbitrarily complex existing Java web systems. (Not forgetting Eclipse GUIs).

If my understanding is correct of that ‘embedding Felix’ page: with Felix, my ‘library’ would NOT be an OSGi plug-in. It would be a normal Java JAR. That means the driver applications (except Eclipse) could access its APIs freely without any nasty class loading shenanigens. Great! Of course, to embed this into Eclipse, I’d have to create an extra plug-in which wrapped this normal JAR. That’s fine.

Within this JAR, it could create an embedded Felix OSGi framework to load the plug-ins it needs. It would do this using Felix.

That all sounds great, but I have three reservations.

Firstly, I’m not familiar with any aspects of OSGi other than simple plug-in loading, and I appear to do that in an Eclipse-specific way. I use org.eclipse.core.runtime.Platform.getExtensionRegistry().getExtensionPoint(…).getConfigurationElements() and then IConfigurationElement.createExecutableExtension in order to instantiate the plug-ins I want. I suspect if I were to switch to another OSGi framework, I’d have to learn to do things a different way since these are Eclipse-specific APIs, and OSGi in general seems much more focused around service provision. Still, I’m sure there’s a way, and it’s my problem :-)

Secondly, the general advice I see from OSGi experts is “make everything an OSGi bundle!” In the above scenario, I’d actually be taking something which is currently a bundle – my library – and making it a plain old Java library (POJL?) However, I think I’ve come to the conclusion that there’s no other way I can expose the APIs to people outside of OSGi, without using things like ‘transloader’, so that’s no surprise.

Finally, though: this presents a problem when I want my system to be used as an Eclipse plug-in. It means that I’d have an embedded plug-in system inside my plug-in, and I wouldn’t be able to use any of Eclipse’s extensive facilities to create and distribute those plug-in plug-ins. (For example, update sites, the update manager, maybe even PDE to create the plug-ins, etc.) That’s unacceptable, and I’d need to find a solution.

I’m hoping that when I find the solution to the first point, and work out the generic OSGi APIs I should be using, it will transpire that there is some ‘extension registry’ interface which is implemented by both Equinox (inside Eclipse) and Felix (outside Eclipse). The user of my library will have to pass some instance of this interface to the library when creating it. If they’re working inside Eclipse, that’s easy to obtain; if they’re working outside, they’ll have to initialise Felix themselves. Not ideal but not awful. I’m not sure if it’s even possible yet! (The plug-ins themselves could hopefully use Import-Package, and would therefore get the main ‘library’ code from the Eclipse plug-in or the Felix ’system bundle’ depending on what was available).

In short: it looks like this could solve the problem, but I’ll need to do some research into non-Equinox-specific ways of loading plug-ins and then find out if those ways can also be used within Equinox. And then find out what other problems pop up!

Thanks again Peter for the useful comment.

Another interesting link, linked from the Felix page, is this:
http://code.google.com/p/transloader/
This was written for the exact purpose I am describing. It takes a tree of objects loaded by one ClassLoader and makes a copy which will work in another ClassLoader. Remarkable!

Meanwhile I’ll have a look into RFC 132 and Felix.

http://www.osgi.org/Specifications/Drafts

Also take a look at the embedding felix pages on the Felix website.

http://felix.apache.org/site/launching-and-embedding-apache-felix.html

The felix model was the role model for the OSGi RFC 132 specification.