Just learned what the heck is OSGi… very fascinating technology but I like to know if you used it in your project.
We used it for some of our multitenant apps.
Basically used for developing independent components (developed in SpringDM) which are deployed on Equinox and exposing them through another webservice component.
Moreover we are also using different versions of the same component exposed to different clients based on their licensing policy.
So now at any point of time if we need to upgrade any customer, we just need to change the dependency for the client component and it rocks…no server restarts (which otherwise would have taken at-least 2 hour of downtime for all customers)
That’s very fascinating use of hot deployment. I read that and in my mind was “So What?”. For example, let say I have a mission critical system that updates some data… Do I really want to keep the application alive and perform hot deployment in middle of critical transaction? For that, I would say “No! Enable Disaster Recovery System”. Still, your use case is very valid. Also, I’ve been looking into Spring DM and Spring DM Server which is now owned by Eclipse community… Does this mean Spring is abandoning it? I don’t understand why they gave it to Eclipse. Also, Spring DM hasn’t been updated since 2009! I wonder if I’m learning a dead technology.
Actually in last 6 months OSGi have been a low profiled project but yes there are active developments being done.
You can look at Apache Aries project, where you will see the active development and regular commits.
OSGi is more related to creating a modularized application, which has very clear dependencies.
The real power of OSGi lies in its classloading policies which was earlier a nightmare. The best example is the conflicts between different versions of log4j.
Issues with the classpath and searching the conflicts between the jar files in a single webapp was earlier a nightmare, even there was no easy to find out the class files being used in case you 2 different version of same jar files loaded in your classpath.
OSGi really helps is solving these kind of use cases.
Somehow what I have experienced is that by this time most of the applications have already implemented their own way of modularizing their apps and to avoid any classpath conflicts they are already following the best practices, so at present they don’t find much use of OSGi .
But still OSGi have its own world and yes you will still find the OSGi implementations in projects which love to define very clear dependencies between their components.
Great info!!
Yeah, I read about “Jar Hell” example for OSGi. In my 10 years of developing in Java, I never had that problem. Yes, I’ve used frameworks that used different version of a library like log4j. At the end, I just choose the latest version and it all worked out. Though I do see a potential problem if some method suddenly disappeared…I’ve yet to experience Jar Hell.
Also, they make a big deal about partial compiling/testing. Usually, when you change a code a IDE like Eclipse will autocompile that single class then you can rerun your test. If you have a daily build then you’re likely to compile and unit test everything. Doesn’t buy too much benefit either.
Lastly… I believe the time your project needs OSGi… it’s already too late… meaning to refactor the code be in OSGi will be an expensive procedure. Still, your hot-deployment is more than enough to be a valid use. However…I don’t think hot deployment is widely used for business reasons. Ehh… what do I know? I only looked at it for half a day.