Re: Enforcing mandatory components for an application

2021-10-13 Thread Raymond Augé 
I don't think "readiness" is something you completely do inside an app to
begin with. (assist with? sure!)

This is why I proposed Condition Service; to model the details required for
your application to be "ready", hoist that into an externally visible (to
the java process) indicator (an open socket, REST endpoint, marker file)
and THEN that can be used by any external readiness checker with whatever
business logic.

Apologies if my recommendation was unclear. But you're likely to have an
orchestrator performing liveness/readiness checking anyway, why even try to
model that entirely inside the application?!?

- Ray

Re: Enforcing mandatory components for an application

2021-10-13 Thread Neil Bartlett 
On Wed, 13 Oct 2021 at 10:06, Bertrand Delacretaz 
wrote:

> On Tue, Oct 12, 2021 at 11:59 PM Neil Bartlett 
> 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
>
>

Re: Enforcing mandatory components for an application

2021-10-13 Thread Bertrand Delacretaz 
On Tue, Oct 12, 2021 at 11:59 PM Neil Bartlett  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.

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.

-Bertrand

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org