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
