This is an interesting problem and I'm also not clear on why Ray suggested the Condition Service as a solution, as I can't see how it helps.
What you're trying to do is somewhat against the grain in OSGi. We assume that the world as open and that failure is never permanent. Just because the HTTP component has not started *yet* doesn't mean that it never will... if you could just install a bundle the right version of some dependency it might all spring into life! But you are building a closed world with a well-defined set of bundles. As the application assembler you know that there will never be another bundle to come along and save the day. Honestly, a launcher-based timeout may still be the best solution, e.g. "HTTP server failed to start within 30 seconds, terminating application". There may be some error conditions that you can detect without having to wait for the full timeout, but you cannot *in general* tell the difference between a component that will never be satisfied and a component that just isn't satisfied yet. On Tue, 12 Oct 2021 at 22:09, Robert Munteanu <romb...@apache.org> wrote: > Hello Ray, > > Thanks for your reply. I read through [1] and also the condition > service specification [3] and I am not sure how this will help me. > > I am looking for a way to say "component X did not come up and will not > come up" and at that moment halt the application. This is a bit of a > closed-world/static approach, but I am fine with it for limited > scenarios. E.g. if binding an HTTP server to port 8080 failed, I would > not like the application to linger and wait for the admin to solve it > and restart the component when done, but it should stop altogether. > > Where would you see the condition service helping here? > > Thanks, > Robert > > [3]: > https://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html > > On Tue, 2021-10-12 at 11:33 -0400, Raymond Augé wrote: > > Hello Robert, > > > > You probably want to use the DS support [1] for the **NEW** _Condition > > Service Specification_ which was added in OSGi Compendium R8 (currently > > in > > the release process). > > > > You can try this out with the current 2.2.0-RC1 of Felix SCR [2] on > > Maven > > Central. > > > > The Condition Service Specification lets you model your application > > conditions (as the name implies) using OSGi service filters. > > > > [1] > > > https://osgi.github.io/osgi/cmpn/service.component.html#service.component-satisfying.condition > > [2] > > > https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr/2.2.0-RC1/bundle > > > > On Tue, Oct 12, 2021 at 5:50 AM Robert Munteanu <romb...@apache.org> > > wrote: > > > > > Hi, > > > > > > I have written a couple of small OSGi apps where if a single top- > > > level > > > DS component, let's call it T, cannot start then the application > > > should > > > shut down immediately. One example are HTTP services where the HTTP > > > server port cannot be bound to. > > > > > > The causes of failures I have seen are: > > > - T activation fails > > > - the bundle providing T fails to resolve > > > - a dependency of T fails activation > > > - a dependency of T cannot be provided because the bundle providing > > > it > > > failed to staret > > > > > > I can think of several ways of approaching the problem, but none of > > > them perfect: > > > - using the Felix Health Checks[1], that seems wrong since it's a > > > polling-based approach and we very likely know when a dependency > > > fails > > > and stop immediately > > > - using the SCR introspection API [2], which is again based on > > > polling > > > - waiting for the framework to start and then looking up the service; > > > but we don't know when the SCR has 'settled' > > > > > > Are there any patterns or libraries that I can use to approach this > > > problem? > > > > > > Thanks, > > > Robert > > > > > > [1]: > > > > > > > https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html > > > [2]: > > > > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection > > > > > > --------------------------------------------------------------------- > > > 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 > >
