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.pogorzels...@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 <njbartl...@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 <maili...@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-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
