EclipseZone - Eclipse extensions versus OSGi services ...

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

Java, the OLPC, and community responsibility

The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!

Replies: 11 - Pages: 1
Threads: [ Previous | Next ]

Reply 2. At 12:52 PM on Feb 11, 2007, Jin wrote:: Re: Eclipse extensions versus OSGi services
Neil:

Thanks for your great article to let me more familar with osgi serivices. I have read through the article. It's really helpful. I'd like also to post my question here. You said, "So, will DS or even Spring-OSGi someday replace the use of extensions in Eclipse? It’s conceivable, yes." Is it your own thinking or the offical preferred consideration of the eclipse committers?
In my view, the extensions V.S. services, is contribution V.S. consumption(in development's view). There are two different thinkings, two different flavours. In some cases, extension mechanism is more straight;In some other cases, DS is. In the aspect of "framework design", extension mechanism is more suitable than services as it could hide maximal implementation detail. Is it possible make both DS and eclipse extension optional in the future osgi standard(or coexist in other ways), rather than get ride of one of them?

Jin
Reply 3. At 2:24 PM on Feb 11, 2007, Neil Bartlett wrote:: Re: Eclipse extensions versus OSGi services
Jin,

Thanks for your comments.

As for the first question - I can't speak for Eclipse committers and I am not a committer myself, therefore what I said is purely my opinion.

DS today is only an optional part of the OSGi specification, and extensions aren't part of the OSGi specification at all (neither is Spring-OSGi). Since these things are built on top of the core framework, it is not necessary for them to be mandatory in the specification for people to continue using them. Neither of them will be "got rid of" as long as a significant community is using them and keeping them alive.

Communities of users are more important to the future of a technology than some specification flagging them as mandatory. Remember EJB Entity Beans...?

Kind regards,
Neil
Reply 4. At 12:22 AM on Feb 13, 2007, Richard Hall wrote:: Re: Eclipse extensions versus OSGi services
I am not sure which tweaks you are referring to that are needed for "on demand" loading of services...

Just for clarification, iPOJO was doing the "simplified programming model" for OSGi before Spring entered the picture, but you are correct that they will probably have more sway for better or worse.

iPOJO was started as an evolution of the Service Binder (and DS) that recognized that the programming model was still too complicated. The nucleus of the idea actually started during the formation of the DS spec, but was too risky to pursue.

iPOJO currently has nearly all of the functionality of DS, including "on demand" services, plus some very interesting extra features all with POJOs and a little bit of byte code manipulation. iPOJO still needs improving, but is probably as stable as most DS implementations.

Luckily, all of these approaches (Service Binder, DS, Spring-OSGi, Dependency Manager, iPOJO) include the same basic concepts that were introduced with Service Binder, so switching among them is not too conceptually challenging, nor does it necessarily have to greatly impact your code.

Thanks for the interesting article.

-> richard
Reply 5. At 12:38 AM on Feb 13, 2007, Edward Yakop wrote:: Re: Eclipse extensions versus OSGi services
Hi,

It is a very nice article. But I have a question in regards to this specific part:

“Extensions are not pure OSGi”. This is not true. The Extension Registry is implemented by the bundle org.eclipse.equinox.registry, which depends on org.eclipse.equinox.common. These bundles are implemented with pure OSGi code. There are no secret hooks into specific features of Equinox (the Eclipse implementation of OSGi) and therefore there is no reason, at least in theory, that extensions cannot be used on other OSGi runtimes such as Apache Felix or Knopflerfish.

i.m.h.o. Extensions are not pure OSGi, that is, It is not possible for OSGi bundle to create a ServiceTracker tracking the service provided by extensions directly.

For example, If I want to track the what consoles being added/removed to the Console view. I couldn't just simply create a service tracker, tracking [IConsoleManager] and add my own implementation of [IConsoleListener].

Obviously, the sentence "that extensions cannot be used on other OSGi runtimes ...", has a very specific meaning in regards what does "used" means.

Regards,
Edward Yakop
Reply 6. At 4:56 AM on Feb 13, 2007, Neil Bartlett wrote:: Re: Eclipse extensions versus OSGi services

Obviously, the sentence "that extensions cannot be used on other OSGi runtimes ...", has a very specific meaning in regards what does "used" means.

It simply means the following: extensions can be used on other OSGi runtimes in the same way they are used on Equinox.

Just because they don't interoperate directly with the service registry doesn't make them "impure". OSGi does not mandate that you use services for everything. On the other hand, if you believe that everything should in fact be done through services, then it's true that extensions are not for you.
Reply 7. At 6:43 PM on Mar 12, 2007, Chris Aniszczyk wrote:: Re: Eclipse extensions versus OSGi services
btw, this is one of the best articles out there today on osgi
Reply 8. At 7:08 AM on Apr 30, 2007, Marcel Offermans wrote:: Re: Eclipse extensions versus OSGi services
Neil, just a small clarification. The dependency manager that is part of Apache Felix now stated its life as an open source component here:

https://opensource.luminis.net/confluence/display/XF/OSGi+bundles

by that time, I also wrote an article about it which was published on the OSGi site:

http://osgi.org/documents/osgi_technology/AutoManageServiceDependencies_byMOffermans.pdf

Andreas Ronge, Anders Janmyr and SCAN COIN have since made some extensions which were documented here:

http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:xenotron; Marcel Offermans -- Software Architect at luminis®.
We actively support open source.
Reply 9. At 11:59 AM on May 7, 2007, rashmy wrote:: Re: Eclipse extensions versus OSGi services
Hi,

I am new to OSGI services and was trying to see if it will help me solve an issue - Here is what I have -

I have written some code so that custom validations on my data model can be added by others dependent on my plugin. For this reason I had to define a new extension point to which a customer can contribute a validation class and I can use his class to perform validations on my data model.

But the issue is I have some command line utilities which were using my plugin to load the data model and validate it. For this I had written a java class with main() method that internally invoked a specific java class to load and validate my model. But after I defined the new extension point I have to create a headless RCP application just to run my command line utility since a headless RCP requires the config.ini and a particular plugin directory structure to have eclipse read the registry and figure out the extensions. So I thought of using the OSGI services, to bypass all this. Is it possible to do this? So should I again create some sort of OSGI application to activate the service activator to register my service and also hanlde stopping of these services?

Thanks..
Reply 10. At 4:37 PM on May 7, 2007, Alex Blewitt wrote:: Re: Eclipse extensions versus OSGi services
The config.ini is an Equinox configuration file, not specific to Eclipse applications. Ditto the plugins/ although actually you can put bundles anywhere and then install them into the framework afterwards if you're not using the update configurator (I'll be posting a tip on this in the near future).

In any case, both OSGi services and extensions need the OSGi system up and running. If you're using Eclipse, you can create an application extension and launch that on the command line with -application foo.

Whilst you may be able to run some code from a main() method, it's a good idea to bring up the OSGi environment in case you have dependencies or services you use at a later stage. If you want to write your own code to launch, you can kick off EclipseStarter to bring it up (see the tips and tricks page; I posted something there recently).

Alex.
Reply 11. At 11:27 PM on May 14, 2007, Rahul wrote:: Re: Eclipse extensions versus OSGi services
Hi Neil,

I enjoyed reading the Eclipse/OSGi article, very nicely written!

Cheers
Reply 12. At 12:53 PM on Jun 7, 2007, Eugene Voytitsky wrote:: Re: Eclipse extensions versus OSGi services
Neil, great thanks for the article.

As I understand 4 months went since the article was published.
Is `Spring-OSGi is in its infancy, and is absolutely not suitable for production usage at the moment` still truth now, after Spring 2.1 and Spring-OSGi 1.0-M2 already released?

Thanks