Well, the tool that we are integrating is not osgi-aware by nature. Its async startup process was design to be called inside a main() method. It runs in its own thread and it is asynchronous because it requires a lot of network and database processing in multiple cloud nodes and its .
I'm wrapping it in a bundle and trying to keep using our standard way that uses DS components and Configurator. Yep, I'll experiment to create a new bootstrap component that do not exposes any service(in order to keep using Configurator), call the startup method inside it and as soon as it completes ok then register the service that will trigger the activation of other components . many thanks, Cristiano On 18/06/2019 12:24, David Jencks wrote: > If I understand, your idea is to basically make this component’s activation > synchronous. If this works, it’s likely the simplest solution. In that case, > is removing the extra thread an option? Another possibility that may bring > its own set of problems is to have this async-startup component not declare > any services but to register its services in code at the completion of the > async startup. It’s been several years since I dealt with something like > this but as I recall it can be difficult to get the async start/shutdown to > work reliably while required dependencies are simultaneously coming and going > on other threads. > > Why does this component need to start asynchronously? > > Thanks > David Jencks > > Sent from my iPhone > >> On Jun 18, 2019, at 6:56 AM, Cristiano <[email protected]> wrote: >> >> Hello all, >> >> We have a system where we use Felix Configurator in order to >> initiate/activate a set of DeclarativeService bootstrap components (with >> configurationPolicy = ConfigurationPolicy.REQUIRE,) as soon as the >> container get started. Those components are triggering the activation of >> other immediate components that referring them with a >> ReferenceCardinality.MANDATORY. >> >> Now I need to integrate with a tool that provides me an async startup >> method and returns a CompletionStage: CompletionStage<InitMeta> >> startup(Config config). >> >> I'm in doubt how would be the best way to deal with this kind of async >> startup process inside the component's activate() method. I must ensure >> that DS will not activate others components before this async tool is >> started and also do not prevent that not related components do activate >> properly. >> >> I have not sure yet, but I think that calling >> startup().toCompletableFuture().get(), a blocking method, will block the >> DS thread and prevent others components from being activated. Also, I >> think that if I don't block then DS will consider this bootstrap >> component activated and will trigger the activation of other components, >> even if the tool's startup do fail later. Am I right? >> >> could someone please give me some tip? >> >> thanks and best regards, >> >> Cristiano >> >>
