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