I think both of those suggestions are rather inappropriate to be used in a DS
component activate method, which generally should not block….. although having
it take a long time is also very much less than ideal.
Certainly the second method seems to imply someone knows how many B2s there
are so the minimum cardinality can be set based on that knowledge, possibly by
whatever code has that knowledge. The (proprietary) metatype/config admin I
work with does this, it can count how many cm Configurations there are for B2
and set properties based on that.
If you make B3 expose a service and not be immediate, then it won’t be
activated until someone needs it and will pick up however many are then
available, even without the cardinality set.
david jencks
> On Sep 7, 2015, at 11:46 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
>
> Just to add a bit of detail…
>
> If you wait for 5 service instances before performing your initialisation,
> that’s great. But bear in mind that you might get a 6th and a 7th very soon
> afterwards, and depending on your implementation you may have to
> re-initialise each time that happens.
>
> If your (re)initialisation is expensive, you might want to avoid doing it too
> many times, especially if there is a rapid sequence of changes. This is
> typically the case during application startup for example. There are two
> general solutions to this:
>
> 1) You could start a timer each time the service set changes. If there are no
> further changes before the timer expires, then you do your reinitialisation.
> If there *are* changes then you cancel the existing timer and start a new one.
>
> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130).
> Whoever is making changes to the set of installed bundles — e.g. the
> launcher, or some kind of management agent like FileInstall — should start a
> Coordination before it does anything, and end the coordination after that
> series of changes. Your component should be a Participant which detects
> whether there is a current coordination. If there is NO current coordination
> then it should immediately action any changes in the service set. However if
> there is a current coordination, then those changes should only be actioned
> when the coordination ends. This has the advantage that you don’t waste time
> waiting for an arbitrary-length timer to expire.
>
> Hope that helps. Regards,
> Neil
>
>
>
>> On 7 Sep 2015, at 16:16, Benson Margulies <ben...@basistech.com> wrote:
>>
>> That is precisely what I needed. Thanks.
>> On Sep 7, 2015 11:06 AM, "David Jencks" <david_jen...@yahoo.com.invalid>
>> wrote:
>>
>>> Hi Benson,
>>>
>>> I don’t really understand what you are asking, but I’m going to guess.
>>>
>>> I think you have say 5 B2 services and you want B3 to wait to activate
>>> until all 5 B2’s are available?
>>>
>>> There is a way to do this with DS 1.3, but you have to make B3
>>> configuration-policy=REQUIRE.
>>>
>>> So you have in B3:
>>> @Component(configuration-policy=REQUIRE)
>>> public class B3 {
>>>
>>> @Reference(cardinality=MULTIPLE)
>>> void setB2(B2 b2) {}
>>> }
>>> In your (required) configuration for B3 you put a property
>>>
>>> B2.cardinality.minimum: 5
>>>
>>> that is, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>
>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>> There’s no guarantee that a bundle starting will start all the DS services
>>> it provides. They might have all sorts of unsatisfied dependencies….. such
>>> as missing configurations.
>>>
>>> Let me know if this guess is a total miss :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>> On Sep 7, 2015, at 10:52 AM, Benson Margulies <ben...@basistech.com>
>>> wrote:
>>>>
>>>> I am hoping that David Jencks will continue his charity to strangers
>>> here.
>>>>
>>>> David, if you have any gogo jiras you'd like help with in return, just
>>> ask.
>>>>
>>>> Three bundles:
>>>>
>>>> B1 registers service S1.
>>>>
>>>> B2 consumes S1 and uses it in the implementation of S2. That is to
>>>> say, it picks up a reference to S1 with a DS @Reference with
>>>> cardinality MANDATORY.
>>>>
>>>> B3 consumes B2, but it anticipates that B2 will have siblings. So it
>>>> consumes a reference to a List<S2> with cardinality AT_LEAST_ONE.
>>>>
>>>> It can take B2 and buddies a bit of time to activate.
>>>>
>>>> I appreciate that the most general case is intended to be that
>>>> services come and go, and B3 should dynamically reconfigure itself.
>>>> I'd rather not do that yet; I'd like to arrange things so that B3
>>>> waits to finish starting itself until all the B2-ish guys are fully
>>>> set up.
>>>>
>>>> Assuming that B2 and friends are all started at an earlier start
>>>> level, is there an 'esthetic' way to arrange this? Or should I really
>>>> suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
>>>> B2 service x=y, block until it's available?'
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>
>
> ---------------------------------------------------------------------
> 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
