I meant all implemented interfaces (although I did wrote all
bundle-exported). I guess everybody agrees there are reasons for
implementing and not exposing. Not that frequent in my opinion. So, the
spec for org.osgi.service.component.annotations.Component.service() should
be:
If not specified, the service types for this Component are all the
<i>directly</i> implemented interfaces of the class being annotated.
without <i>directly</i> in it. But that's just my opinion. It would really
make it easier for people familiar with other DI frameworks - for some
reason all of them take type hierarchy into account when wiring.
Thanks for the explanations!
Pawel
On Thu, Feb 5, 2015 at 10:04 PM, Ferry Huberts <maili...@hupie.com> wrote:
>
>
> On 05/02/15 21:21, Milen Dyankov wrote:
>
>> Agree to some extend. However here is what I meant with a stupid example.
>> Say I have GUI where I can dynamically add buttons to perform operations
>> on
>> something. If I could do
>>
>> @AutoRegisterComponentsFromClassesImplementingMe
>> public interface Button {
>> void performActionOn (Something something);
>> }
>>
>> public abstract class AbstractButton implements Button {
>> // some common logic here
>> }
>>
>> then I could say to my not-so-keen-about-osgi colleagues "You know what,
>> just extend the AbstractButton, add your logic, build (tooling will make
>> it
>> a bundle), deploy and your button will appear in the UI"! Again it's NOT
>> that there is some crucial missing feature in OSGi / DS but rather a
>> matter
>> of convenience!
>>
>>
> And why is that adding just one tiny step ('put @Component on your class')
> is too difficult?
>
> Besides, there are many valid reasons for implementing an interface and
> _not_ exposing it as a service, also for your button case.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
