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
