So it looks like we lost most of the thread but to try to keep this from
turning into more of a tangled ball of yarn the cat played with….
1) NO!!!!!:
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setAllComponents(List<WorkerComponentService> allComponents) {
This might be a blueprint-ism but DOESNT WORK FOR DS!!!!
The event methods (bind/unbind/updated) don’t have to be called anything in
particular but they need to take only ONE service/service reference/properties
NOT a collection.
So
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setWorkerComponentService(WorkerComponentService wcs) { …}
If you use DS 1.3 reference fields it can be a collection valued field. I’ve
never used these except possibly in some tests.
2) the minimum cardinality property has to be supplied from config admin, not
component.xml. So it is runtime modifiable. I might have missed it but I
didn’t see what your configuration was or how you were installing it. You
cannot set the minimum cardinality at compile time.
I think you are making life too hard for yourself. From your description, when
you set up the deployment of your stuff, you know exactly how many
WorkerComponentService instances to expect, so you can put that value in the
configuration. Then DS will do the waiting for you, and your restful service
component will get the references and activate once the appropriate number are
ready. If you expect to have more WorkerComponentServices registered, say 10,
and want to restrict yourself to only using a particular 5 of them, you can,
along with the cardinality to assure you get at least 5, use a target filter to
find the exact 5 you want. For instance, if the WorkerComponentServices have a
“type” property that identifies which one they are, your filter in the
configuration would look something like
WorkerComponentService.cardinality.minimum=5
WorkerComponentService.target=“(|(type=foo1)(type=foo2)(type=foo3)(type=foo4)(type=foo5))”
Wiring up DS services is really powerful. I haven’t figured out the exact
computational strength available but to me it has the feel of logic programming.
thanks
david jencks
> On Sep 7, 2015, at 2:55 PM, Benson Margulies <ben...@basistech.com> wrote:
>
> I think I now understand what I have failed to explain here (and I
> probably know why my service is acting like tantalus).
>
> My plan is to create a series of docker containers. Call them
> 'workers'. Each worker publishes the same restful service; each one of
> them handles one or more 'tasks'. The worker accepts work via a single
> RESTful service, and dispatches the work to the tasks based on
> parameters in the requests to the service.
>
> The set of tasks implemented on a particular worker is controlled the
> set of OSGi bundles I provision in it. I have a whole slew of them,
> each registers a 'RosetteComponentService'.
>
> Each of these task bundles has, potentially, a bit of a startup delay
> as it gets organized.
>
> I don't want to open the restful service until the components are all set up.
>
> In spite of all the email I've sent up to this point, it dawns on me,
> a bit belatedly, that my own configuration file for a worker does list
> the components that it expects to find.
>
> So, I can set up a protocol where the restful service component waits
> for all the components to 'light up' and then lights itself up, since
> it knows what is supposed to be there. But not at compile time, so I
> can't use a cardinality property.
>
> One approach would be to @Reference the list, and then do a little
> sleep loop waiting until everyone arrives. I am going to go read on
> event admin to see if I can use that to sleep on an event that would
> indicate that a new example has shown up.
>
> Thanks for all your patience; I think this much will keep me out of
> your hair for a while.
>
> ---------------------------------------------------------------------
> 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
