On Tue, 2021-10-12 at 22:59 +0100, Neil Bartlett wrote: > 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.
Right, I may end up doing something based on the following signals: - bundles failed to start -> abort - framework started -> start a timer - service registered after the framework started -> re-start the timer - after the timer fires if the mandatory components are not available - > abort I am aware that this is somewhat of an edge case and not fully mapped on the OSGi model, but I kind of like OSGi so I'm exploring different scenarios with it. Thanks, Robert > > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
