On Wed, 13 Oct 2021 at 10:06, Bertrand Delacretaz <bdelacre...@apache.org> wrote:
> On Tue, Oct 12, 2021 at 11:59 PM Neil Bartlett <njbartl...@gmail.com> > wrote: > > ...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... > > In such cases, I think having a PERMANENT_FAILURE state for services > would be useful, and that's where you would decide to give up. > There is the FAILED_ACTIVATION state already, which would certainly be a specific error case that you can detect before waiting for a full timeout. Sadly it's not enough for the general case. If the component is waiting for a service reference then it will be UNSATISFIED, we don't know if it will become satisfied soon. Unsatisfied is not a failure state! You could dig deeper and try to work out why the referred service isn't available but this requires quite a bit of knowledge of bundle internals, e.g. "I know bundle X should provide this service but it is unresolved". > > I don't think there's such a concept for OSGI services, if I had to > implement that I would probably implement my own "failed services > registry" where services can indicate that they're hopelessly dead. > Each service can then decide on their own when that happens, probably > based on service-specific timeouts. > This would require abandoning a lot of Declarative Services and all of its advantages, instead doing all your service lookups directly in code. > > -Bertrand > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
