felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: How to 'let the dust settle' with DS?
Date Mon, 07 Sep 2015 15:16:15 GMT
That is precisely what I needed. Thanks.
On Sep 7, 2015 11:06 AM, "David Jencks" <david_jencks@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 <benson@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-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message