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