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_jen...@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.pogorzels...@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 <njbartl...@gmail.com> > wrote: > > > >> Services in OSGi are intended so that you can implement many interfaces > >> but publish under a subset. Therefore the set of published services > must be > >> listed explicitly. > >> > >> Neil > >> > >> > >> On Thursday, 5 February 2015 at 16:15, Pawel Pogorzelski wrote: > >> > >>> Thanks Ferry, it indeed works. Is there any way of doing it without > >>> specifying all the object supertypes during the registration? Maybe > using > >>> Felix SCR annotations instead of OSGi ones? > >>> > >>> Cheers, > >>> Pawel > >>> > >>> > >>> > >>> On Thu, Feb 5, 2015 at 5:02 PM, Ferry Huberts <maili...@hupie.com> > >> wrote: > >>> > >>>> > >>>> > >>>> On 05/02/15 16:59, Pawel Pogorzelski wrote: > >>>> > >>>>> Guys, > >>>>> I have a generic interface IRepository<T> extended by > >> IAppleRepository, > >>>>> IOrangeRepository and so on. Concrete implementations like > >> AppleRepository > >>>>> are registered in the container with non-generic interfaces like > >>>>> IAppleRepository. Is it possible to tell DS engine I need every > >> service > >>>>> sublassing IRepository? Corresponding line in my component.xml looks > >> like > >>>>> follows: > >>>>> > >>>>> <reference name="Repository" cardinality="0..n" policy="dynamic" > >>>>> interface="com.Whatever.IRepository" bind="addRepository" > >>>>> unbind="removeRepository"/> > >>>>> > >>>>> but it doesn't work. I'm on Felix 4.4.1. > >>>> > >>>> > >>>> Then the bundles don't advertise the IRepository interface but their > >>>> subclass(es). > >>>> > >>>> Make the bundles advertise IRepository and it'll work. > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >>>> For additional commands, e-mail: users-h...@felix.apache.org > >>>> > >>> > >>> > >>> > >> > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- http://about.me/milen
