Felix Meschberger wrote > Hi, > > Am Samstag, den 15.01.2011, 11:16 +0100 schrieb Carsten Ziegeler: >> Yes, but in these cases all components implementing the service would be >> active though only one is used. > > No. As long as you only have the ServiceReference in hand delayed > components are not (fully) activated, i.e. the classes not instantiated > (and potentially not even loaded). > Yepp exactly - I realized this directly after sending my mail above :)
But still, using this technique your component has a 1..n reference to a service though actually it's a 1..1 (or 0..n vs 0..1). Thanks Carsten > Regards > Felix > >> >> Regards >> Carsten >> >> BJ Hargrave wrote >>> Or SortedSet.first() :-) >>> >>> This is assuming you use a Collections.reverseOrder() comparator. >>> Otherwise the first element is the lowest ranking. >>> -- >>> >>> *BJ Hargrave* >>> Senior Technical Staff Member, IBM >>> OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_ >>> [email protected]_ <mailto:[email protected]> >>> >>> office: +1 386 848 1781 >>> mobile: +1 386 848 3788 >>> >>> >>> >>> >>> >>> >>> >>> From: Felix Meschberger <[email protected]> >>> To: OSGi Developer Mail List <[email protected]> >>> Date: 2011/01/14 21:18 >>> Subject: Re: [osgi-dev] [DS] Improve reference support ? >>> Sent by: [email protected] >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Hi, >>> >>> Albeit a bit clumsy it is also possible using an internal Sorted >>> collection. The reference is converted to a multiple one and the >>> ServiceReferences are kept in, say, a SortedSet such that the service >>> with the highest ranking is always provided by >>> sortedSet.iterator().next(). >>> >>> Regards >>> Felix >>> >>> >>> Am Freitag, den 14.01.2011, 11:34 +0100 schrieb Peter Kriens: >>>> Isn't this easily handed by a little helper class? >>>> >>>> Kind regards, >>>> >>>> Peter Kriens >>>> >>>> On 14 jan 2011, at 11:27, Carsten Ziegeler wrote: >>>> >>>>> Hi, >>>>> >>>>> we're using declarative services a lot - it's usually sufficient and >>>>> works pretty well :) >>>>> >>>>> The only drawback we're facing - and I've heard this from others as well >>>>> - is the lack of proper support for references and the service ranking >>>>> property: once a reference is bound it is not updated if a new component >>>>> providing the same service but with a higher service ranking arrives. >>>>> So, it gets more unpredictable and depends on the startup order of >>>>> services to what service such a reference is bound. >>>>> In these cases, you can't use DS. >>>>> >>>>> It would be great, to have a way to exactly define a reference that is >>>>> always bound to the service with the highest ranking. To be compatible >>>>> this has to be something new as we shouldn't change the current >>>>> behaviour. So maybe adding a new optional property to the reference tag >>>>> in the XML specifying if a rebound should happen due to service ranking >>>>> or something along these lines. >>>>> >>>>> WDYT? >>>>> >>>>> Regards >>>>> Carsten >>>>> -- >>>>> Carsten Ziegeler >>>>> [email protected] >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> [email protected] >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Carsten Ziegeler [email protected] _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
