Hi Georg, Merging the 2 implementations oas-startupfilter + -disabler and oas-starter-startup makes fully sense to me, although I am bit hesitant by replacing the basic approach.
these 2 have a rather static assumption, when the application is up, and their sole purpose is to indicate that. And once the system is up, it's up and this state remains unchanged until the startupfilterDisabler is deactivated. A healthcheck based implementation can changed its mind based on many factors, you already mentioned the fact that key services should be available. If these services go down during runtime, the status of this check changes. If I understand you correctly, then the semantic of the startup itself might not change, but it's more likely, that the unavailability of such a key service would cause the Filter to kick again, changing runtime-behavior; currently it does not. Is this intended? Jörg Am Sa., 6. Apr. 2019 um 00:24 Uhr schrieb Georg Henzler <[email protected] >: > Hi all, > > we have currently two mechanisms in Sling to wait for startup: > > * sling-org-apache-sling-startupfilter + > sling-org-apache-sling-startupfilter-disabler > * sling-org-apache-sling-starter-startup (only used for the starter > application AFAIK) > > Now that systemready in Felix is fully migrated to Felix Health Checks I > would like to rely on ServiceUnavailableFilter [1] instead. The > advantage is that this filter can be configured in a declarative fashion > (what is required to be alive can be configured, e.g. for a customer > project it's easy to wait for additional custom services) and 503 is > also correctly sent upon shutdown. > > Is this approach something everyone is ok with? > > -Georg > > [1] > > https://github.com/apache/felix/blob/trunk/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
