Patrick Paulin is a trainer and consultant specializing in modular technologies such as OSGi and the Eclipse Rich Client Platform. He spends much of his time offering the RCP Quickstart course, which is meant to get software developers up to speed with Eclipse RCP. Patrick is also a regular speaker at technology conferences such as EclipseCon and Eclipse World. Patrick is a DZone MVB and is not an employee of DZone and has posted 24 posts at DZone. View Full User Profile

Making OSGi Easier

06.04.2009
| 6805 views |
  • submit to reddit

While there are a ton of benefits to be gained from adopting OSGi, it’s not a trivial task to migrate your existing code. Class loader issues can bite you and perhaps the biggest pain-point is the migration of third-party libraries.

Third-party libraries are a problem because while bundle repositories are growing in size, there are still a lot of JARs out there not packaged as OSGi bundles.

So what can we do to make it easier to adopt OSGi?

The Knoplerfish answer

Well it turns out that the Knoplerfish OSGi framework has solutions to many of these issues. Among the features offered are:

  • Automatic runtime generation of manifests for non-bundle JARs
  • Automatic patching of code that uses inappropriate (for OSGi anyway) class loading mechanisms
  • Ability to execute static main methods inside of the framework

These solutions are covered in detail in this presentation given last year.

Why are these solutions not more popular?

I’m wondering why these types of solutions are not discussed and suggested more. Are there similar features in Equinox and Felix that I’m not aware of? And if not, are there any plans to implement them?

I’d love to hear from others whether features like these would be useful to you or not. I’d also be interested to hear what else could be done to make OSGi adoption easier. In my opinion, the difficulty of migrating applications to OSGi is one of the main things holding it back. What can we do to fix this?

From http://rcpquickstart.com/

Published at DZone with permission of Patrick Paulin, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mladen Girazovski replied on Thu, 2009/06/04 - 6:04am

Automatic runtime generation of manifests for non-bundle JARs

I don't think that this is feasable/a good idea.

After all, it doesn't take much to create an OSGi Bundle from a non OSGi Bundle Version, and a lot's of OSGified Bundles are already available from certain repositories,automatic conversion have their drawbacks, as everything that works magically/automatic.

Automatic patching of code that uses inappropriate (for OSGi anyway) class loading mechanisms

 Again, i don't think that this is feasable, some Libraries (ie commons-logging) are so deeply flawed that they shouldn't be used in an OSGi Environment, unless you're looking for trouble.

 Ability to execute static main methods inside of the framework

 I don't see the point of that.

 I think the problem is that migration is not that easy and will never be, as with any new technology/framework/API, migrating to OSGi  is not nessecary an real improvement for most old Applications, since they aren't structured to take benefit from OSGi (no vertical partitioning).

 

Heiko Scherrer replied on Thu, 2009/06/04 - 8:59am

Hi all, I prefer the BSD tool (http://www.aqute.biz/Code/Bnd) to convert non-OSGi bundles in OSGi-fied bundles, I read about that tool in Daniel Rubios book about Spring and OSGi.

Patrick Paulin replied on Thu, 2009/06/04 - 3:14pm

Hi mgira,

Thanks for the response and I agree that migration is never an easy process. It's also true that features like these allow developers to skip the step of properly structuring their code to benefit from OSGi. They also might result in frustration when the auto behavior doesn't work as planned.

But I think that it's useful to think of migration to OSGi as a long-term process that involves repeated refactorings based on always runnable code. If you have to do a lot of refactoring just to get to a runnable state, then many developers will give up or not be interested to start with.

My point is that it might be useful to think of "regular" JARs as bundles, just really bad ones. This is similar to the process many went through when migrating from procedural languages to OO ones. Many people dumped their procedural code into OO and while the classes were extremely ugly, it ran. Some (hopefully most) used this as a starting point for a refactoring into a truly OO design.

Mladen Girazovski replied on Fri, 2009/06/05 - 2:09am

I see your point(especially about always having runnable code) and i have to agree, if migration is as easy as possible (even if the result is not a "clean" or better typical OSGi app), more projects could be moved faster and proper refactoring (needs running code) could  be done sooner.

Richard Hall replied on Fri, 2009/06/05 - 3:58pm

Generating bundle metadata is not the difficult part, the difficult part is understanding the JAR's behavior. Just because you have metadata, it doesn't mean you are correctly initializing the bundle or shutting it down. Some libraries require static initialization or use threads, metadata won't help you here. Now, if they can auto-generate the proper bundle activator, then it might be interesting. :-)

I doubt Felix would ever include any of these features in its framework. They are all risky and give a false sense of security. Besides, most of these can easily be implemented as a layer on top of the framework if people really want them, so it is better to avoid putting this stuff in the core.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.