However there is a caveat. If you use the UPDATE field strategy, supplying your own collection or map implementation then ordering is up to you.
- Ray On Thu, Mar 9, 2017 at 10:36 AM, Konrad Windszus <konra...@gmx.de> wrote: > I was too quick with my last response. > > On 9 Mar 2017, at 16:33, Konrad Windszus <konra...@gmx.de> wrote: > > > > Hi Ray, > > thats what I assume as well, but I couldn't find that explicitly > specified in DS 1.3. If I did not oversee that it would be IMHO good to > explicitly state that in the DS 1.4 Spec. WDYT? > > What is the process of getting an issue resolved in a newer spec version? > > Thanks, > > Konrad > > > >> On 9 Mar 2017, at 16:27, Raymond Auge <raymond.a...@liferay.com> wrote: > >> > >> I do believe the order is always reversed natural ordering on the > ServiceReference. > Actually it is not the reversed natural ordering but the natural ordering > (i.e. lowest ranked first!), see 112.3.8.1 in OSGi 6 Compendium > "Before the component instance is activated, SCR must set the field with > a new mutable collection that must contain the initial set of bound > services sorted using the same > ordering as ServiceReference.compareTo based upon service ranking and > service id." > > >> > >> i.e. > >> - first; ordered by service.ranking property in descending order > (highest ranked first) > >> - second; ordered by service.id property in ascending order (oldest > first) > >> > >> HTH, > >> - Ray > >> > >> On Thu, Mar 9, 2017 at 10:15 AM, Konrad Windszus <konra...@gmx.de> > wrote: > >> Can anyone comment or this, or do you want me to open a Bugzilla issue? > >> Thanks, > >> Konrad > >>> On 3 Mar 2017, at 08:42, Konrad Windszus <konra...@gmx.de> wrote: > >>> > >>> Hi, > >>> DS 1.3 added field injection and now supports Collections/Lists. > Unfortunately it is only specified (in OSGi R6 Comp, §112.3.8.1) how those > are ordered in case of dynamic references. What about having a static > reference with multiple cardinality? > >>> I fail to see the according spec about the ordering of these. > >>> Is this an oversight on my side, or is this just missing from the spec? > >>> Can I assume that those are ordered as well according to > ServiceReference.compareTo(...)? > >>> Thanks, > >>> Konrad > >> > >> _______________________________________________ > >> OSGi Developer Mail List > >> osgi-dev@mail.osgi.org > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >> > >> > >> > >> -- > >> Raymond Augé (@rotty3000) > >> Senior Software Architect Liferay, Inc. (@Liferay) > >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) > >> _______________________________________________ > >> OSGi Developer Mail List > >> osgi-dev@mail.osgi.org > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > > OSGi Developer Mail List > > osgi-dev@mail.osgi.org > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
