Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » E4 @Named dependency injection and OSGi services
E4 @Named dependency injection and OSGi services [message #902056] Wed, 15 August 2012 16:49 Go to next message
Fabio Mancinelli is currently offline Fabio Mancinelli
Messages: 16
Registered: July 2009
Junior Member
Hi everybody,

I am trying to do the following without luck: I am writing a bunch of
OSGi plugins that will provide services that will be used in an E4
application.

I have an interface IStorage that is implemented by different plugins,
each one providing a particular type of storage (e.g., local, remote, etc.)

Now, I would like to be able to choose the particular "type" using
@Named annotations, something like

@Inject
@Named("remote")
IStorage remoteStorage

The problem is that I cannot make it work.

In my pure OSGi plugin I've tried the following:

1) Creating a declarative service that provides the IStorage interface
and whose name is "remote".

2) Getting an Eclipse context in my plugin's activator using
EclipseContextFactory. getServiceContext(bundleContext); and putting the
"remote" implementation in it using context.set("remote", new
RemoteStorage())

They both don't work.

So the question is: is it possible, in a pure OSGi world, to use E4 DI
to provide different services implementing a given interface and
selecting them using the @Named annotation?

Thanks,
Fabio

P.S.: Registering a service using bundleContext.register(IStorage.class,
new RemoteStorage(), null) works perfectly when I try to @Inject
IStorage somewhere. The problem is that in this way I cannot select one
implementation when multiple ones are available.
Re: E4 @Named dependency injection and OSGi services [message #902143 is a reply to message #902056] Thu, 16 August 2012 06:30 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
No - e4 DI will always pick the first one it finds. The @Named
annotation will simply make the DI container search for a key "remote"
instead of "IStorage.class.getName()"

You could invent you own annotation which searches the OSGi-Service
registry differently.

So you'd write:

@Inject
@OSGiNamed("remote")
IStorage remoteStorage

Tom

Am 15.08.12 18:49, schrieb Fabio Mancinelli:
> Hi everybody,
>
> I am trying to do the following without luck: I am writing a bunch of
> OSGi plugins that will provide services that will be used in an E4
> application.
>
> I have an interface IStorage that is implemented by different plugins,
> each one providing a particular type of storage (e.g., local, remote, etc.)
>
> Now, I would like to be able to choose the particular "type" using
> @Named annotations, something like
>
> @Inject
> @Named("remote")
> IStorage remoteStorage
>
> The problem is that I cannot make it work.
>
> In my pure OSGi plugin I've tried the following:
>
> 1) Creating a declarative service that provides the IStorage interface
> and whose name is "remote".
>
> 2) Getting an Eclipse context in my plugin's activator using
> EclipseContextFactory. getServiceContext(bundleContext); and putting the
> "remote" implementation in it using context.set("remote", new
> RemoteStorage())
>
> They both don't work.
>
> So the question is: is it possible, in a pure OSGi world, to use E4 DI
> to provide different services implementing a given interface and
> selecting them using the @Named annotation?
>
> Thanks,
> Fabio
>
> P.S.: Registering a service using bundleContext.register(IStorage.class,
> new RemoteStorage(), null) works perfectly when I try to @Inject
> IStorage somewhere. The problem is that in this way I cannot select one
> implementation when multiple ones are available.
Re: E4 @Named dependency injection and OSGi services [message #902228 is a reply to message #902143] Thu, 16 August 2012 12:51 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 1049
Registered: July 2009
Senior Member

@Tom: I think it would be a nice extension if OSGi service could be searched by name. Is it worth opening a bug for that feature request?
Re: E4 @Named dependency injection and OSGi services [message #902249 is a reply to message #902143] Thu, 16 August 2012 14:11 Go to previous messageGo to next message
Fabio Mancinelli is currently offline Fabio Mancinelli
Messages: 16
Registered: July 2009
Junior Member
On 08/16/2012 08:30 AM, Tom Schindl wrote:
> No - e4 DI will always pick the first one it finds. The @Named
> annotation will simply make the DI container search for a key "remote"
> instead of "IStorage.class.getName()"
>
Thanks Tom for your reply.

What you said was clear to me. It was just the I thought that the @Named
annotation, somehow, affected also the way the OSGi services were searched.

As Lars suggested maybe a feature request here makes sense because
since OSGi declarative services have a provided interface and also a
name, this perfectly fits the use case

@Inject @Named("component-name") ProvidedInterface service;

Thanks,
Fabio


> You could invent you own annotation which searches the OSGi-Service
> registry differently.
>
> So you'd write:
>
> @Inject
> @OSGiNamed("remote")
> IStorage remoteStorage
>
> Tom
>
> Am 15.08.12 18:49, schrieb Fabio Mancinelli:
>> Hi everybody,
>>
>> I am trying to do the following without luck: I am writing a bunch of
>> OSGi plugins that will provide services that will be used in an E4
>> application.
>>
>> I have an interface IStorage that is implemented by different plugins,
>> each one providing a particular type of storage (e.g., local, remote, etc.)
>>
>> Now, I would like to be able to choose the particular "type" using
>> @Named annotations, something like
>>
>> @Inject
>> @Named("remote")
>> IStorage remoteStorage
>>
>> The problem is that I cannot make it work.
>>
>> In my pure OSGi plugin I've tried the following:
>>
>> 1) Creating a declarative service that provides the IStorage interface
>> and whose name is "remote".
>>
>> 2) Getting an Eclipse context in my plugin's activator using
>> EclipseContextFactory. getServiceContext(bundleContext); and putting the
>> "remote" implementation in it using context.set("remote", new
>> RemoteStorage())
>>
>> They both don't work.
>>
>> So the question is: is it possible, in a pure OSGi world, to use E4 DI
>> to provide different services implementing a given interface and
>> selecting them using the @Named annotation?
>>
>> Thanks,
>> Fabio
>>
>> P.S.: Registering a service using bundleContext.register(IStorage.class,
>> new RemoteStorage(), null) works perfectly when I try to @Inject
>> IStorage somewhere. The problem is that in this way I cannot select one
>> implementation when multiple ones are available.
>
Re: E4 @Named dependency injection and OSGi services [message #902344 is a reply to message #902249] Fri, 17 August 2012 08:31 Go to previous messageGo to next message
Sopot Cela is currently offline Sopot Cela
Messages: 597
Registered: December 2010
Senior Member

Well the @Inject in e4 is meant primarily to inject dependencies which basically means decouple the interface from the implementation. While I agree there may be cases that direct implementation reference from the client of the injection is appropriate (OSGi services maybe one of them) , in general I think it should not be encouraged by the framework as DI is the highest level of implementation-hiding patterns.

The @Named does influence the way services are searched but searches for a specific named interface (service) in the context, not a specific implementation for a given interface.

Maybe one solution would be to plug in a context function and let it pick the implementation based on the context. If you are in a "remote" context the CF can select the remote variant of IService, if you are in a "local" context it should select the local one. But your client code would be just @Inject IService and the logic of the implementation switching would be a small and easy extension to the framework.

Maybe I ranted too much but I hope this helps.
Re: E4 @Named dependency injection and OSGi services [message #902360 is a reply to message #902344] Fri, 17 August 2012 10:16 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 1049
Registered: July 2009
Senior Member

@Sopot: It feels to me that you are missing a key point here. OSGi services can be named, see here: http://www.vogella.com/articles/OSGiServices/article.html#declarativeservices

The request here is that this name can be used in the @Named tag. This would not introduce any hard implementation coupling IMHO. I think it would be consistent with the DI approach and would allow to select specific OSGi implementations based on the name similar to Context Variables.
Re: E4 @Named dependency injection and OSGi services [message #902803 is a reply to message #902228] Mon, 20 August 2012 14:01 Go to previous messageGo to next message
Joseph Carroll is currently offline Joseph Carroll
Messages: 174
Registered: May 2012
Location: Milwaukee, WI
Senior Member

+1
If we know the service is in the OSGi context then it would avoid the unnecessary search up the tree (cleaner and more efficient). I might modify it to something like:
@OSGiNamed(name="someName", tag="someTags")
This way it would be possible to differentiate multiple providers.

JD
Re: E4 @Named dependency injection and OSGi services [message #988988 is a reply to message #902803] Tue, 04 December 2012 07:49 Go to previous messageGo to next message
Simon Gregor Ebner is currently offline Simon Gregor Ebner
Messages: 1
Registered: November 2012
Junior Member
Are there any updates on this topic?
I am looking for the exact same functionality.
Re: E4 @Named dependency injection and OSGi services [message #1151704 is a reply to message #988988] Wed, 23 October 2013 14:41 Go to previous messageGo to next message
Eric Moffatt is currently offline Eric Moffatt
Messages: 118
Registered: July 2009
Senior Member

Lars, could you open a defect for this if you haven't already ?
Re: E4 @Named dependency injection and OSGi services [message #1151711 is a reply to message #1151704] Wed, 23 October 2013 14:49 Go to previous message
Lars Vogel is currently offline Lars Vogel
Messages: 1049
Registered: July 2009
Senior Member

I think we would need a new ExtendedObjectSupplier for this, as this is a special case. It is relatively easy to create something like this in a customer implementation. See http://www.vogella.com/articles/Eclipse4OwnAnnotations/article.html
Previous Topic:How change node background color of a disabled Tree-Viewer.
Next Topic:TreeViewer with huge amount of data
Goto Forum:
  


Current Time: Sat Oct 25 10:21:07 GMT 2014

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

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