Equinox
From APIDesign
(→Equinox is not OSGi Framework) |
(→Equinox is not OSGi Framework) |
||
| Line 11: | Line 11: | ||
Nevertheless, some people are asking for [[Equinox]] support in [[Netigso]]. I was a bit reluctant to start [[Netbinox|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. | Nevertheless, some people are asking for [[Equinox]] support in [[Netigso]]. I was a bit reluctant to start [[Netbinox|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 [[Netbinox | + | 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 [[Netbinox|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. | 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. | ||
Revision as of 07:32, 6 October 2009
Another implementation of OSGi. Can be merged with NetBeans Runtime Container via the Netigso project and it yields surprisingly good results. Standard info at wikipedia::Equinox_OSGi.
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.
<comments/>
Follow
