OSGi is a PITA: Bundles
July 2nd, 2008I feel the need to rant about OSGi for a bit. Too many people are hailing it as the solution to everything and anything, and it can be a serious PITA sometimes.
Today’s topic (one of many that are on my mind) is bundles.
Bundles are a PITA.
The recommended OSGi practice is that you turn every JAR into a “bundle” so that it is OSGi compliant. I have to echo what Steve Loughran said this week about this: tool choices should not be transitive [1]. I shouldn’t have to force every upstream project to get on the OSGi bandwagon. A JAR should not have to be OSGi compliant, a JAR is something that somebody gives to me and I should not have to changed. Ideally it is signed so I wouldn’t even want to change it.
Requiring the OSGi headers in a bundle manifest also breaks the way we work with many tools [2]. Take Maven or Ivy for instance. They download JARs for my application from a common public repository. What happens when a JAR is not OSGi enabled? You end up having to do crazy things like having your own version of a Maven repository.
So why should I have to modify a JAR to be able to deploy things in an OSGi container? Or why should a softare provider have to supply this information upstream? It seems to me that a better way to go about this would be to have an OSGi supplemental metadata repository. Given JAR X we could download the missing OSGi information. An OSGi container could just assemble these two things on the fly.
Am I missing something here? Why would people develop such an invasive model?
1. While I did not investigate in depth, I do have to slightly disagree with the stance taken on his blog. ODE should make it easier for Maven users and distribute the transitive dependency information. But, that doesn’t mean Maven has to be the build system for ODE. Just means they have to distribute POMs.
2. Don’t give me crap about how OSGi has been around longer or how we should just ensure that everyone has OSGi headers. We don’t live in an OSGi only world.
July 3rd, 2008 at 2:52 am
I think you miss the point in that an OSGi bundle is still just a jar, and can be used as such. It’s not an either/or situation. And there are repositories (springsource, for example) that provide ready made bundles of open source projects for those that don’t provide headers.
Lastly, the tool you’re proposing here exists already and is called “bnd”, which takes a jar and can amend it or wrap it without changing the bits in the original Jar.
July 3rd, 2008 at 4:43 am
> …It seems to me that a better way to go about this would
> be to have an OSGi supplemental metadata repository…
I like the idea, created https://issues.apache.org/jira/browse/SLING-563 to remind us to add this to Sling at some point.
July 3rd, 2008 at 5:25 am
Depending on your use case it is often completely valid to work with plain old jars in an OSGi environment. The way to do this is via the Bundle-Classpath OSGi header.
If you are building some new OSGi application that depends on classes from a plain old jar and those classes never need to be passed between OSGi code in different bundles. Then in this case you can embed the jar containing the classes directly into your bundle and add it to the local classpath of your bundle via the Bundle-Classpath header.
This gives you a deployable unit of code that automatically contains all code needed to function. Compared to a standard J2SE approach where you need to suppliment the local classpath with all the dependencies of a given jar.
Situations where this well works is when the jar provides functionality such as xml serialization, database access, an http server or any other non api/data objects.
The benefit of this pattern is that it is non invasive to the existing jar (as far as the jar is concerned it is just running within a standard java environment - where the classpath is defined by the parent OSGi bundle)
The downside of it is that if multiple bundles reuse the same library then it gets loaded multiple times. But then this is no worse than standard hierarchical J2SE classloading.
Finally as Alex pointed out there are more and more OSGi enabled jars becoming available so I think that this problem will for the most part become an edge case vs a common problem in the long term.
So in summary OSGi gives you options, you get to choose how you want to structure your modules.
July 3rd, 2008 at 8:00 am
> Am I missing something here?
Yes. Simply treating OSGi as yet another war/ear clone is not going to help one bit with the actual problems of nonmodular existing code, which more often than not assume a free-floating big pile of spaghetti dependencies that “more or less” happens to work at runtime, hopefully, mostly - though often nobody really knows why anymore.
Automagic bundlefication (which is IMHO a strange idea since it makes development and deployment even less deterministic?) would only “fix” the *least* important hurdle of OSGi and still do nothing to *force* people to think hard about visibility, lifecycles and cycle-free transitive dependencies.
Nothing forces you to require or create OSGi versions of all your dependencies - *that’s the point*. You can bundleize in iterations, safely isolated.
> Why would people develop such an invasive model?
To quote Jonathan Rentzsch: “better necessarily means different”. The problem is not that OSGi is invasive (it is, because it has to fix a significant deficiency in Java), but rather that the lack of visibility enforcement was a good idea to begin with. OSGi merely forces people to finally pay for a long-running design debt.
July 3rd, 2008 at 1:15 pm
Good points. Also consider that OSGi versioning and meta data does not play well with other environment s- for example, we had a nightmare of a time integrating Maven style version strings with OSGi style versions for Terracotta Integration Modules (all Terracotta Integration Modules are OSGi bundles)
I can provide you a real-world instance of the upstream problem you mention.
http://www.kimchy.org/compasslucene-terracotta-integration/
When I worked with Shay Banon of Compass to enhance Compass to integrate with Terracotta, one of the things he had to do was turn Compass into an OSGi bundle - so it could be a Terracotta Integration Module - because every TIM is an OSGi bundle. Luckily, he didn’t have too much trouble doing this - and we were sitting next to one another during the process. I can imagine it would have been a lot more difficult if there wasn’t a personal interest involved - let’s say I approached random project X and asked them to be Terracotta Integration Module compliant - now they have to also be OSGi bundle compliant too. Not every project is going to just jump on board with that idea - and that is definitely a problem to consider.
July 3rd, 2008 at 1:45 pm
[...] « OSGi is a PITA: Bundles [...]
July 3rd, 2008 at 3:28 pm
To make the point more explicitly clear, as Alex points out, adding OSGi metadata to a JAR file does not impact anyone else using the JAR file upstream as a normal JAR file. If it worked before, it will work with OSGi metadata afterwords because this just adds some properties in the JAR manifest. If you are running into difficulties, then it is likely not the fault of OSGi metadata.
However, the same is not true if you take an OSGi bundle and try to use it as a standard JAR file, since bundles can have things like embedded JAR files and native libraries.
Lastly, it is not a fault of OSGi that it doesn’t integrate well with Maven version numbers any more than it is a fault that Maven doesn’t integrate well with OSGi version numbers, but yes, OSGi was around for a lot longer so is we want to try to cast blame…
July 4th, 2008 at 2:00 pm
@All: see my latest post, but in summary my gripe is that most OSGi tools require that you distribute the metadata inside the jar. But its META-data, it should be able to be distributed separately. I shouldn’t have to modify upstream JARs to be able to use them to their full extent in an OSGi repository.
In other words: it is non-necessarily invasive.
@David: see the comment from Andrew in my latest post why Bundle-Classpath does not work for us.
July 5th, 2008 at 12:15 am
“my gripe is that most OSGi tools require that you distribute the metadata inside the jar. But its META-data, it should be able to be distributed separately” … “In other words: it is non-necessarily invasive”
I have to disagree with this. Would you say that the use of class or method access modifiers is unnecessarily invasive, or suggest distributing this information separately?
OSGI export/private headers are very similar in that they are used to define visibility (at the package rather than method/class level) and along with the import header used to define modularity. The only difference I see is that Java has always had access modifiers but has never had any mechanism to declare and enforce modularity.
You can only consider these “non-necessarily invasive.” if modularity is not of importance and you are forced to add these headers in order to be able to deploy to a certain framework/platform. On the other hand If modularity is important then these headers are as important as Java access modifiers and should be considered an integral part of the API. Of course, in the case of OSGI/hot-deployment modularity is important.
July 5th, 2008 at 11:58 pm
I’d also point out that, in the extreme, you can simply put all your “normal” jars in the class path - just like you usually did - and then use boot classpath delegation for everything. You don’t get anything out of doing this, but it shows that OSGi is quite easily backward compatible in the way that some seem to find absolutely necessary.
But to go to the original point of “tool choices should not be transitive”… Man, I just have to kind of scratch my head with that one. I mean, even in the physical engineering world this statement is blatantly false. I’m not sure why on earth anyone believes a choice of tool doesn’t have huge implications down the line. Granted, it doesn’t *have* to have transitive implications but there isn’t a law that says this is normal or to be expected…
July 6th, 2008 at 3:07 pm
@Daniel: No I would not say that the use of class/method access modifiers are unnecessarily invasive. But you can’t run a Java app without this. You can run a Java app without OSGi headers. Hence, they’re optional headers. And I feel that you should be able to distribute these headers separate from the jar.
I’m not saying that the OSGi headers aren’t important. I just think that requiring them inside the JAR is a barrier to usability.
July 15th, 2008 at 11:08 am
An OSGi bundle is supposed to be a *self-contained* component, i.e. the very notion of adding *extraneous* metadata to a wannabe component aspiring to become a *real* component goes against one of OSGi’s biggest advantages.
So the day separating bundle and metadata becomes a widespread habit will be the way I’ll be leaving the OSGi bandwagon.
That being said, you could have a look at
http://wiki.ops4j.org/confluence/display/ops4j/Pax+URL+-+wrap
if you really want to wrap classic jars als OSGi bundles on the fly.
August 29th, 2008 at 5:32 pm
free slot machine on line…
incloses gloriously avail?Bailey?bauble …
August 30th, 2008 at 8:13 pm
flood insurance zones…
altar!ventricle Bambi:…
September 1st, 2008 at 12:24 am
data entry mass property insurance…
postmortem Harpy telemetry potbelly dissimilar:…
September 9th, 2008 at 1:48 am
giocare alla roulette europea regole della roulette online ai…
prefacing Basel attune Xebec …
September 11th, 2008 at 2:18 am
sizzlingslots…
gong?Junes latent hangover lamb …
September 16th, 2008 at 9:53 am
insurance quotes for cars…
holding:leadership Alsatian?…
September 18th, 2008 at 10:37 pm
two pair holdem…
fatteners.Bailey:monster ingenious accordance …
September 20th, 2008 at 5:10 am
the best free money no deposit required casino…
respecting curler:sheet scores musings dismissals …