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 21:03:25 GMT
One of the principles we've tried to keep to in DS is that all the information about what to
do is in the xml descriptor and we don't do significant runtime analysis of capabilities and
we definitely don't do runtime class scanning.  So it sounds like you are proposing a tectonic
shift in the philosophy behind DS which is unlikely to happen any time soon.  Having dealt
with annotation processing for javaee I cannot express how strongly I am against runtime annotation
processing for DS.

thanks
david jencks

On Feb 5, 2015, at 3:41 PM, Milen Dyankov <milendyankov@gmail.com> wrote:

> So as I mentioned earlier you have 2 options:
> 
> (a) build time - which is exactly how @Component annotations are processed.
> Basically treat every class implementing the interface as if it was
> annotated with @Component and @Service
> 
> (b) deploy / run time - which is more or less what you suggest although I
> can imagine different implementations
> 
> So I fully agree with you that it can be done. But in the context set by
> the original question:
> 
> - Is this possible with DS as of now - AFAIK no
> - is it something that DS/SCR should support - I don't know. I think it
> could, but again there may be implications I'm not aware of.
> 
> 
> 
> 
> 
> 
> On Thu, Feb 5, 2015 at 9:29 PM, David Jencks <david_jencks@yahoo.com.invalid
>> wrote:
> 
>> 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
>> 
>> 
> 
> 
> -- 
> 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