On Wed, 2021-10-13 at 11:17 -0400, Raymond Augé wrote: > 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?!?
I agree with your points for most scenarios. The one where I think the situation is not that clear-cut is when running batch/non-interactive applications which don't serve external requests. Running an HTTP service with a liveness check enforced by an orchestration platform or settings timeouts feels like a kludge when it is "obvious" that the application is not able to advance. Working with other DI frameworks was IMO simpler in this case - when a required object could not be instantiated they failed loudly and aborted the application. Again, I am aware that this is not the OSGi service model, but that doesn't mean I can't try and shoehorn it to fit my problem space. I will probably fight back, but I can try :-) Thanks, Robert --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
