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
