> On Sep 7, 2015, at 5:06 PM, Benson Margulies <[email protected] > <mailto:[email protected]>> wrote: > > On Mon, Sep 7, 2015 at 4:07 PM, David Jencks > <[email protected] <mailto:[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.
No, if you’re sure you know how many there will be you can just use the cardinality property. I was showing the target filter approach in case you wanted a specific subset of the available services, and you want to be sure to get all the ones you want and exclude all the others. thanks david jencks > >> >> 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] >>> <mailto:[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] >>> <mailto:[email protected]> >>> For additional commands, e-mail: [email protected] >>> <mailto:[email protected]> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]>
