Equinox
From APIDesign
Equinox is another implementation of OSGi specification. Can be used together with the NetBeans Runtime Container via the Netbinox subproject of the Netigso effort and it yields surprisingly good results (in spite Equinox not being ready for execution in modular environment and has own compatibility problems).
Contents |
Equinox is not OSGi Framework
Recently I have upgraded my Netigso project to Felix 2.0. It took a while as I needed to find new tricks to convince Felix to do classloading the way I like. I had this working in 1.4 version, but as this was done via reflection, which is obviously not a public API of Felix, the new tricks were quite different than those used in 1.4 version.
Nevertheless, some people are asking for Equinox support in Netigso. I was a bit reluctant to start such project. My attitude towards OSGi is still not through-fully positive and thus I thought support for one OSGi container is enough. But today was Friday, there was nothing better to do, so I gave Equinox a try.
It is amusing to look at different implementation of the same API! Both Felix and Equinox are supposed to work the same, yet both are coded in quite a different way. While Felix seems to adhere to OSGi spec as close as possible, the Equinox is full of additional abstractions and hooks exposed as API for integrators. As a result I seem to be able to integrate Equinox into Netigso without any wild tricks (like using reflection). One of the available hooks is actually exactly what I need.
It seems to me that Equinox is not by itself an OSGi container. It is prefabricate made for others (Eclipse & co.) to create their own OSGi containers. This is quite a different approach compared to the one taken by the Felix. While Felix adheres to the spec, avoiding containerisms as much as possible, majority of Equinox are various API extensions to tweak or enrich the standard OSGi behaviour.
As a result Felix seems to be the right framework for those who start with modularity and want to be as close as possible to the OSGi specification (Glassfish comes to my mind). Equinox on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to bridge it to OSGi. Just like I have to do in my Netigso sub-project.
Upgrading Equinox
The Netbinox project (which provides the fastest OSGi container on the Earth for launching desktop applications) is based on top of Equinox. Originally I started with Equinox version 3.5, but recently some customers requested an upgrade to the newly released 3.5.2 version.
I am not doing any non-API tricks while using Equinox. I rely either on OSGi interfaces or Equinox extension hooks. No reflection, no access to implementation details, etc. As such I was expecting the upgrade to be as easy as dropping new version of equinox.jar into the system.
That was naive expectation. It was significantly more complex!
Functional Incompatibility
My code needs to find out all packages in each bundle to optimize classloading. I started to use
Enumeration en = bundle.findEntries("", "", true);
and such code works quite fine with Felix and Equinox 3.5. However it does not work at all in Equinox 3.5.2!
What that implies? Well, the Equinox implementation is shaking like an amoeba. In one release something works, in other it does not. Shakes like this obviously complicate usage of such libraries due to increasing fear to upgrade. Upgradability is no longer guaranteed, it is associated with problems and additional tweaks. One needs to seek for a workaround (in my case I had to re-read the OSGi specification and adjust the code):
Enumeration en = bundle.findEntries("", null, true);
Now the code works in Felix and all versions of Equinox I am aware of. In spite of the workaround, there still remains a BackwardCompatibility problem in Equinox. Something that used to work (in old version and also different implementation of the same API) no longer works in newer versions.
One can pretend that this is not a problem - e.g. the OSGi specification does not prescribe behavior of empty string being passed in as second parameter. An answer like: you have not read the specification properly, would then be appropriate. But hey, I am clueless user of the API! It is not my job to read specs, it is my job to get my code run! And it used to run. Even on two different implementations!
One can also admit that this is a problem. In such case there shall be new test, preferably in a TCK, to ensure Equinox is not vulnerable to the amoeba effect. In today's email conversation Richard Hall confirmed that the spec seems to indicate empty string shall match nothing. Richard reported himself a bug, so next release of Felix will be functionally incompatible with its previous release too. And the Amoeba is shaking and shaking...
<comments/>
Richard S. Hall said ...
I guess you are right (although there is always way to provide AlternativeBehaviors), it is better to follow the spec (especially if the TCK is improved to cover the case). On the other hand, this is not true containerism: the (mis)behavior was the same in Equinox 3.5 as well as in Felix. Otherwise I would find out I need to pass in null sooner.
--JaroslavTulach 18:03, 14 July 2010 (UTC)
Richard S. Hall said ...
Yeah, it was unfortunate that there was a similar issue in both. I've added a test case for this for Felix at least, but one should probably be added to the OSGi CT too.
--Richard S. Hall 20:10, 14 July 2010 (CEST)
Prakrathi said ...
That is completely unbalstendadre.I've been contemplating doing this as well, but was wondering how you approached those specific hurdles.I'm not a lawyer, but the OPC specs are published under the RCL (never heard of it) but it states under the RCL your changes, bug fixes, extensions, etc. must be made available to the community. I figure the term community ties the source and changes back to foundation members.If we do tackle this, I would hope to make it official (as Utgard is on the OPC website) but also be able to keep it open-source.Thank you for your feedback!
--Prakrathi 08:29, 21 October 2013 (CEST)
Dewi said ...
Forcing users to get a pay tool to do what a different open soucre tool does is not a strategty that will win long term. We want people writing snazy code, and we want it in eclipse right? SWT designer is nice, my team purchased it. But it doesn't beat Matisse, and it's a glaring failure of Eclpse as a whole.Asking users to buy a book (even the Eclipse RCP book) doesn't seem like a good strategy either. It's not that the documentation isn't out there, it's that it seems to have been written bya bunch of fuedal lords, none of whom care to share their technology with each other and make a aactual real integrated tool and documentation set out of it.I have looked at Eclipse Riena, and I like lots of it, but once again, how does this technology mix and match with everything else? Not well it seems.
--Dewi 02:44, 22 October 2013 (CEST)
Alex Blewitt said ...
Actually, most of this post is a fabrication. Equinox is an OSGi framework, as evidenced by the fact that it passes the OSGi TCK, without which it couldn't be called an OSGi framework. So the assertion that 'Equinox is not an OSGi framework' is incorrect.
It does highlight something that people often get confused by; OSGi is not meant to be an exclusive specification of 'you can only use this'. It's supposed to be *modular*. And as such, you can add modules to bring your own functionality on top of any system; you're not 'limited' in some arbitrary way to only use those modules as specified in the OSGi spec.
Equinox, by itself, is a standalone OSGi engine. The framework differs from Felix's implementation in that the console is bundled in the 'org.eclipse.OSGi' framework bundle; whereas in Felix it's a separate engine.
But services like the extension registry are provided in their own bundle as a separate OSGi bundle. Just because the extension registry isn't defined in the OSGi core spec doesn't mean it's not OSGi - it's just another layer on top, much like the reference impl for remote services is handled by using different underlying bundles (e.g. ECF or SOAP).
Lastly, OSGi isn't a 'constraining' system which means that you are locked into precisely one way of working. In fact, until 4.2, there wasn't even a standard set of properties to bring up a framework; they were all non-standard properties in that way. At least that's starting to normalise.
--Alex Blewitt 12:11, 11 October 2009 (CEST)
Thanks for speaking up Alex. The title of my post was intentionally more radical than the content. All I wanted to point out is that Equinox (in contrast to Felix) is a meta framework. To turn it into actual OSGi framework you can apply various tweaking functions to it and thus obtain various OSGi frameworks. Obviously one of such tweaking functions can be identity (e.g. no change) yielding OSGi framework known as Equinox. But the meta capacity is something interesting and I wanted to point it out.
--JaroslavTulach 11:12, 12 October 2009 (UTC)
Follow
I'm not a believer in being backwards compatible with bugs, otherwise there'd be no end. The spec is the law of the land in the OSGi world, so that's what bundles should expect to get. If we weren't strict with that, then bundles would continue to depend on containerisms even after they were corrected.
--Richard S. Hall 03:50, 14 July 2010 (CEST)