felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: OSGi Declarative Services dependency on a generic supertype
Date Thu, 05 Feb 2015 19:32:32 GMT
The @Component implementation has a default for the registered services all directly implemented
interfaces. The reason for this default is readability, the annotation and the default value
are close together so a reader has all the knowledge close together. Using your proposed scheme
would make the actual value depend on outside information that could change and wreak havoc,
eg one of your super classes in potentially a different bundle implementing a listener interface
causing an extra service to be registered. 

This is also the reason why the DS annotations are not inherited. Though this can sometimes
kill sharing, it definitely makes things more predictable and therefore readable. Since reading
in most long living apps is much more important than the one time writing that seems a valid
trade off.

Therefore, the current default is IMHO still by far the best. The enemy of good engineering
is quite often automating too much.

Kind regards,

      Peter Kriens

Verstuurd vanaf mijn iPhone

> Op 5 feb. 2015 om 19:06 heeft Pawel Pogorzelski <pawel.pogorzelski1@gmail.com>
het volgende geschreven:
> Alright, thanks Neil. I can see can see some corner cases where this
> behavior could would be desired. It's just the default that bothers me - I
> think by default a service should be registered under all the
> bundle-exported interfaces. After all, if you want to hide implementation
> you do it differently - by defining a public interface and hiding the rest
> in private packages. The same with lookups - if you want to get a specific
> instance then OSGi filters is the way to go. So, if you're relaying on not
> registering under all interfaces probably means there's something wrong in
> your design or the container you run in.
> PaweĊ‚
>> On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett <njbartlett@gmail.com> wrote:
>> Services in OSGi are intended so that you can implement many interfaces
>> but publish under a subset. Therefore the set of published services must be
>> listed explicitly.
>> Neil
>>> On Thursday, 5 February 2015 at 16:15, Pawel Pogorzelski wrote:
>>> Thanks Ferry, it indeed works. Is there any way of doing it without
>>> specifying all the object supertypes during the registration? Maybe using
>>> Felix SCR annotations instead of OSGi ones?
>>> Cheers,
>>> Pawel
>>>> On Thu, Feb 5, 2015 at 5:02 PM, Ferry Huberts <mailings@hupie.com>
>>> wrote:
>>>>> On 05/02/15 16:59, Pawel Pogorzelski wrote:
>>>>> Guys,
>>>>> I have a generic interface IRepository<T> extended by
>> IAppleRepository,
>>>>> IOrangeRepository and so on. Concrete implementations like
>> AppleRepository
>>>>> are registered in the container with non-generic interfaces like
>>>>> IAppleRepository. Is it possible to tell DS engine I need every
>> service
>>>>> sublassing IRepository? Corresponding line in my component.xml looks
>> like
>>>>> follows:
>>>>> <reference name="Repository" cardinality="0..n" policy="dynamic"
>>>>> interface="com.Whatever.IRepository" bind="addRepository"
>>>>> unbind="removeRepository"/>
>>>>> but it doesn't work. I'm on Felix 4.4.1.
>>>> Then the bundles don't advertise the IRepository interface but their
>>>> subclass(es).
>>>> Make the bundles advertise IRepository and it'll work.
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message