You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Pawel Pogorzelski <pa...@gmail.com> on 2015/02/05 16:59:18 UTC
OSGi Declarative Services dependency on a generic supertype
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.
Cheers,
Pawel
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Neil Bartlett <nj...@gmail.com>.
Pawel,
I disagree, and I believe the OSGi specification disagrees with you.
Implementing an interface is a class-level concern. There are many reasons to implement an interface on a class that don’t imply any desire to communicate outside the module via that interface. For example, supporting callbacks.
Ultimately you can make this work either way, but OSGi has to pick a default, and (as we see with package exports) OSGi always chooses the default of hiding as much as possible within the bundle except where a developer makes an explicit choice to expose.
Regards,
Neil
> On 5 Feb 2015, at 18:06, Pawel Pogorzelski <pa...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Milen Dyankov <mi...@gmail.com>.
Understood! As I said it's not that it's something crucial missing! However
at least some alternative to iPOJO's @Stereotype would be nice.
On Thu, Feb 5, 2015 at 10:03 PM, David Jencks <
david_jencks@yahoo.com.invalid> wrote:
> 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 <mi...@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 <mi...@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 <mi...@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
>
>
--
http://about.me/milen
Re: OSGi Declarative Services dependency on a generic supertype
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <mi...@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 <mi...@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 <mi...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Milen Dyankov <mi...@gmail.com>.
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 <mi...@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 <mi...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <mi...@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 <mi...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Milen Dyankov <mi...@gmail.com>.
You are right! My bad! I should have called the interface '
AVerySpecificButtonThatCanOnlyBeUsedWithThisParticularUsecase' ;)
Luckily Java allows you to make use of more than one interface in your
application so all the other valid reasons can be covered too ;)
On Thu, Feb 5, 2015 at 10:04 PM, Ferry Huberts <ma...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
http://about.me/milen
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Pawel Pogorzelski <pa...@gmail.com>.
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 <ma...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Ferry Huberts <ma...@hupie.com>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Milen Dyankov <mi...@gmail.com>.
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 <mi...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <mi...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Milen Dyankov <mi...@gmail.com>.
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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <pa...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Peter Kriens <pe...@aqute.biz>.
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 <pa...@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 <nj...@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 <ma...@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
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Pawel Pogorzelski <pa...@gmail.com>.
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 <nj...@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 <ma...@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
> > >
> >
> >
> >
>
>
>
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Neil Bartlett <nj...@gmail.com>.
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 <ma...@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
> >
>
>
>
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Ferry Huberts <ma...@hupie.com>.
On 05/02/15 17: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?
Don't know about SCR annotations, never used them.
In general your bundles should really advertise only/all of the
interfaces you want/need.
Your bundles can also advertise _only_ the supertype.
It really depends on your needs.
So, no clear answer :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Pawel Pogorzelski <pa...@gmail.com>.
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 <ma...@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
>
>
Re: OSGi Declarative Services dependency on a generic supertype
Posted by Ferry Huberts <ma...@hupie.com>.
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