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_jen...@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 <milendyan...@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_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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- http://about.me/milen