On Mon, Sep 7, 2015 at 4:07 PM, David Jencks
<[email protected]> wrote:
> 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….
I'm sorry to be so poor at communicating.
>
>
> 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.
Oh, so they get called more than once? Yea, apparently I caught a
social disease from Blueprint!
>
> 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.
OK, I get it. That does simplify things.
>
> 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))”
Do I really have to enumerate the types if I happen to have
provisioned only the ones I want.
>
> 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 <[email protected]> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
