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 mainmethods 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?
Rename it! Yes renaming OSGi could help, who understand what OSGi is from the name? and from the descriptions you find googling ? is impossible people don’t get it until they realize they need it and is too late. Videos, tutorials, animations, drawings to explain what OSGi is. Help from Sun?
Hey – just found this post through the new OSGI planet feed. I am super impressed at how Knoplerfish has done this byte code patching – it is an absolute nightmare to deal with the legacy classloader code, especially the jaxb constructs.
Another sticky situation is system properties – I’d say that that could be handled this way as well.
I have asked myself the same question – why is this problem not tackled in other platforms?
It seems to me that other platforms simply get around the problem by making environment changes – but this is not an option when you don’t control your environment (installing into client sites etc). We’ve resorted to modifying libraries so they are better behaved.
Good info, I’ll be looking into this. Any way to isolate the byte code patching from the framework?
Hi Lindsay,
I haven’t looked into the exact way in which the byte code patching is implemented. My guess is that it’s buried in the core framework code, but maybe not. If this is something that would make a difference to you, you might want to file a feature request against Felix or Equinox (not sure which you use).
Also, I’ve suggested a talk on this topic for EclipseCon called “Does OSGi have to be hard?”.
https://www.eclipsecon.org/submissions/2011/view_talk.php?id=2066&search=osgi+hard
If the talk is accepted I’ll be looking for experiences like yours to illustrate the problem. If you’d be willing to share more details offline, let me know.
— Patrick