Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » OSGi declarative services vs context functions for injection(Any good practices on how to consume services within a RCP application ?)
OSGi declarative services vs context functions for injection [message #1437074] Fri, 03 October 2014 21:33 Go to next message
Thomas Elskens is currently offline Thomas ElskensFriend
Messages: 159
Registered: September 2014
Location: Brussels - Belgium
Senior Member
Hello,

I was wondering : when contributing plugins as services to a RCP application, it happens frequently those services depend on other services. When injecting those dependencies, we have the choice : either we use the Eclipse runtime DI (with the annotations) by means of a context function, or we use the more "standard" OSGi DI with a reference tag in the service declaration file.

My question now is to know if there any guidance about how to choose the one or the other ?

My own guess is to use the OSGI-way as much as possible, as it seems to be a more general method than the Eclipse DI and, moreover, it doesn't unnecessarily put things in the Eclipse context. On the other hand, using context functions should be restricted to cases in which RCP-specific services have to be injected (like PartService, Eventbroker, selectionService, and so on).

This reasoning makes sense to me, but I admit I have no clue about reliability, performance... of the two options ? Any advice on this question ?

Thomas Elskens
Re: OSGi declarative services vs context functions for injection [message #1438642 is a reply to message #1437074] Mon, 06 October 2014 09:59 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6580
Registered: July 2009
Senior Member
The dependency should be at the layer where they are needed. Both are
valid ways and as you said you should stick as long to OSGi+DS IMHO as
you can but I also often find me using ContextFunction and the reason is
simple: OSGi-Services are singletons in the VM (well there's the
possibility of ServiceFactory) and ContextFunctions allow me to create
Singletons on an MApplication, MWindow, MPerspective, ... context which
is important when you are targeting a Multi-User VM e.g. when using RAP.

The important part is that the receiver (=the final user) does not have
to be changed if you want to switch later on.

The next versions of efxclipse.core will provide some more helper stuff
in this area washing the difference between OSGi and ContextFunction but
it's not yet in any repo because I've just started designing and using it.

Tom

On 03.10.14 23:33, Thomas Elskens wrote:
> Hello,
>
> I was wondering : when contributing plugins as services to a RCP
> application, it happens frequently those services depend on other
> services. When injecting those dependencies, we have the choice : either
> we use the Eclipse runtime DI (with the annotations) by means of a
> context function, or we use the more "standard" OSGi DI with a reference
> tag in the service declaration file.
> My question now is to know if there any guidance about how to choose the
> one or the other ?
> My own guess is to use the OSGI-way as much as possible, as it seems to
> be a more general method than the Eclipse DI and, moreover, it doesn't
> unnecessarily put things in the Eclipse context. On the other hand,
> using context functions should be restricted to cases in which
> RCP-specific services have to be injected (like PartService,
> Eventbroker, selectionService, and so on).
> This reasoning makes sense to me, but I admit I have no clue about
> reliability, performance... of the two options ? Any advice on this
> question ?
> Thomas Elskens
Previous Topic:Create a multis select combo box or something similar
Next Topic:Multiple Filters To A JFACE Table
Goto Forum:
  


Current Time: Sun Jan 17 20:12:27 GMT 2021

Powered by FUDForum. Page generated in 0.02263 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top