So the JSON configuration is the only place where you know which services must be registered?
Then maybe the following will work. - create a 'meta' component that is a servicetracker - get the relevant JSON configuration into it so that it knows which services must be available. - register a 'meta' service once all tracked services are available, unregister when either one of those becomes unavailable - make your application have a mandatory dependency on the 'meta' service. On 28/08/13 10:32, Roland wrote: > Hello David! > > Thank you for the quick reply!!!! > > > David Jencks wrote >> If you have an unknown number of services how, conceptually, can you know >> when all of them are registered? > > This is my problem. The only one which has the required information, is the > SCR. > If not all factories (DS) have been registered, the JSON-configuration can > not be deserialized. > > > David Jencks wrote >> If you actually do know which services a client needs then the simplest >> solution is to make the client a DS component with mandatory references to >> the services it needs. When the client shows up, you can be sure all the >> services it needs are available. > > This is a good idea, but I want to keep the system stupid. Thus, I don't > want to define which DS (factory) is required. Dependencies must emerge from > the JSON-configuration. > > But, I have a sixth idea: I could prove if all components are in state > "STATE_ACTIVE". > But It may happen that all components are in state STATE_ACTIVE but some > component-descriptions are still not considered. When does the SCR notice > that a component has to be added? > > > > -- > View this message in context: > http://apache-felix.18485.x6.nabble.com/How-To-Wait-until-all-DS-are-registered-tp5004727p5004730.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Ferry Huberts --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
