« Stuff I found, or more accurately, stuff that found me... | Main | How to profile locks with Terracotta (stay tuned) »
April 14, 2008
OSGi delivering on the promise
posted by ari
I just spent the day at TheServerside Symposium in Las Vegas watching integration between 2 frameworks. Once the integration was complete, it was time to bundle the integration into a nice consumable kit. The question was, how? The answer was OSGi.
We use OSGi to allow people to:
1. bundle up some config that ends up inlined / included in another config file (nesting and all the goodness included)
2. code insertion / introduction where you add methods, interfaces, and more to existing and already compiled classes.
3. Code replacement where you change / overload methods, classes, etc.
Say, for example, you want to build a simple included bit of config. You need to write a file called terracotta.xml which is a fragment of a tc-config file. Then you need to set up the manifest for OSGI bundle activation as follows (taken from http://www.terracotta.org):
Bundle-Description: MyApp/MyFramework Cluster Configuration
Bundle-DocURL: http://www.myorg.org/doc/terracotta-integration-module/
Bundle-Name: Terracotta integration module for MyApp/MyFramework
Bundle-SymbolicName: org.myorg.myapp.integration_module
Bundle-Vendor: MyOrg, Inc.
Bundle-Version: 1.0
Note that you can just use our maven tim (terracotta integration module) archetype to stub out a new module that you can then add files to as appropriate.
What's exciting about OSGi to me and what I think makes it work really well for us is not that we can augment apps and frameworks at runtime with what appears to be 3 lines of xml:
What excites me is that people can use OSGi to build modules that just appear to be jars to the untrained eye. I didn't think about this when first watching the team integrate OSGi. We knew we wanted to use OSGi to give ourselves hot-pluggable modules. We just didn't think too much about the resulting jar still being a proper jar. Compass, for example, has always shipped as a clean and simple jar library to be integrated and linked through the classpath. It is still the same, but if a terracotta installation is present and an appropriate
Never thought about it but OSGi doesn't just give us hot-pluggable modules. It gives you, the user, the ability to write a library that auto-clusters in the presence of the clustered runtime yet is a simple jar to your development team.
I love it.
Trackback Pings
TrackBack URL for this entry:
http://blog.terracottatech.com/cgi-bin/mt/mt-tb.cgi/49
Comments
Just saw this now ...
To confirm, we can hot-swap bundles/TIM's ?
Can this be used with TIM's that have roots ?
Can this be used with TIM's that just have code ?
Posted by: t at February 20, 2009 10:25 AM
t: not exactly. TIMs are built as OSGi bundles and loaded into our own private OSGi sandbox. This does not mean you can control our TIMs lifecycle inside the JVM.
--Ari
Posted by: ARI ZILKA at February 23, 2009 8:06 PM