me @ Twitter
Bundle selection extended – what if… March 18, 2008
OSGi provides developers with plenty of configuration and selection mechanisms to adapt your application perfectly to a certain environment. One of these features is the usage of native code. Other than plain Java in OSGi you can simply define a header like the following:
Bundle-NativeCode: lib/superDuper.dll;
osname = WindowsNT;
processor = x86;
selection-filter="(net.mjahn.sample.windowing=win32)";
language = en;
language = de
Now doing this in a fragment is a very nice feature. If your environmental requirements are met, your fragment gets attached to the host and the correct library will be loaded by your OS. On the other hand, if you deploy that fragment on another machine with let’s say a Solaris OS, it simply won’t get resolved. The advantage is you can just create an assembly with all native libraries for the different OS versions and systems in different fragments. Depending on your environment, the container will figure out, which fragment to choose and attach to the host. Piece of cake, I would say.
Recently I was faced with a similar, but unfortunately more difficult problem. I wanted to provide two different bundles containing a distinct implementation of a specific API as fragments; depending on the OS it is running on. On first sight, it is the problem, I already discussed, but on a second view, I realized that it is actually plain Java. The API, I am providing in my fragments is OS dependent, but doesn’t contain native code. I thought, I could work around it, by providing something like a selection-filter or anything similar to the mechanisms of the Bundle-NativeCode header, but there isn’t. (If I am wrong here, please enlighten me, but I haven’t found anything in the 4.1 OSGi core specification!).
Of course, if you have the possibility, you can just implement your own mechanisms to do what OSGi does for native code, just with plain old Java code. Check the environment and load the correct libraries or even simpler, just only provide the correct fragment versions. This is all true; it definitely would work that way. The question, I am asking myself is more, shouldn’t this actually be an infrastructural concern? Shouldn’t the infrastructure be able to decide what is necessary and suits best? In my opinion, one of the big advantages of OSGi is the expressiveness of constraints. Everything is explicit, so from my point of view, it is logical to enable such declarative dependencies without native code as well.
One question remains: Where should this mechanism be added? Like with singleton bundles together with the “Bundle-SymbolicName”? I wouldn’t say so. I think the “Bundle-RequiredExecutionEnvironment” would be a perfect spot for that. A selection based on System properties is flexible, yet distinct enough, so the already introduced “selection-filter” could be applied here. The execution environment in general fits the scope of this property way better than any other, already defined in OSGi.
Well, unfortunately, I am not an OSGi member and the next spec will take a while to come, so I guess this is nothing to be expected any time soon, if at all 
Maybe I am wrong about all that, because I am missing something, but I actually haven’t found any evidence stating the opposite. Till then, I hope for the best – a more compatible (IT) world.
– Mirko
