felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com.INVALID>
Subject Re: OSGi Declarative Services dependency on a generic supertype
Date Thu, 05 Feb 2015 20:29:05 GMT
I still don't understand in your example what is supposed to create an instance of your button
class.

I think it's pretty odd, but I think with my proposal for extension annotation processors
for DS and metatype annotation processing  in bnd, if you were willing to use DS and mark
the button class you actually want to be a real live button with @Component so DS knows enough
to create one, you could write an extension processor that would find your @AutoRegister annotation
on the interface in the inheritance hierarchy and add it to the exposed services.

thanks
david jencks

On Feb 5, 2015, at 3:21 PM, Milen Dyankov <milendyankov@gmail.com> 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!
> 
> 
> 
> 
> On Thu, Feb 5, 2015 at 8:46 PM, David Jencks <david_jencks@yahoo.com.invalid
>> wrote:
> 
>> With DS and the spec annotations, if your component class directly
>> implements the interface, it will be registered as a service exposing that
>> interface.
>> 
>> If your class is not a DS component, I'm not sure what you expect to
>> create an instance of your class in order to register it as a service..  I
>> guess you could register a byte-code weaver that looked for classes
>> implementing your interface of interest, and added byte code that got the
>> bundle context from the class loader, and registered the instance in the
>> service registry, but I don't think you would actually find that very
>> useful as there would be no way to specify service properties in order to
>> distinguish different instances.  It would certainly interfere with any
>> existing component model such as DS or blueprint and probably with any
>> attempt to register a service in code.
>> 
>> david jencks
>> 
>> On Feb 5, 2015, at 2:37 PM, Milen Dyankov <milendyankov@gmail.com> wrote:
>> 
>>> I may be interpreting Pawel's case wrong but I also have had situations
>> in
>>> the past where I wish I was able to somehow mark a interface (by using
>>> annotation for example) and basically say "whoever implements that
>>> interface should be automatically registered as a service"! AFAIK that is
>>> not possible with SCR/DS although it may be very convenient in some
>> cases.
>>> 
>>> Now if such feature was to be implemented the question is weather it
>> should
>>> happen at run/deploy time (probably expensive) or build time (rather a
>>> matter of tooling and not strictly related to DS). However there may also
>>> be some side effects I have not thought about and perhaps a good reason
>> not
>>> to have it.
>>> 
>>> Just my 2 cents
>>> 
>>> Best,
>>> Milen
>>> 
>>> On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
>> <david_jencks@yahoo.com.invalid
>>>> wrote:
>>> 
>>>> The default for scr annotations is to expose all the directly
>> implemented
>>>> interfaces.  If you want something else you can explicitly list the
>> classes
>>>> to expose in the @Component annotation.. This is really easy to
>> understand
>>>> from the class itself.  You can re-list an interface implemented by a
>>>> superclass or that is a super-interface of a directly implemented
>> interface
>>>> if you want, that won't hurt your class.  Your proposal of "all
>>>> bundle-exported interfaces" seems really restrictive and odd to me, any
>>>> directly implemented interface from another bundle (say from a spec)
>> would
>>>> force you to not use the default.  To understand what the component
>> exposes
>>>> you would also have to try to figure out what the bundle exports, which
>> is
>>>> not obvious from the component class itself.
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>> On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski <
>>>> pawel.pogorzelski1@gmail.com> wrote:
>>>> 
>>>>> 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
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> http://about.me/milen
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 
> 
> 
> -- 
> http://about.me/milen


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


Mime
View raw message