On Fri, Jan 18, 2019 at 11:08 AM Georg Henzler <[email protected]> wrote:
> Hi Ray,
>
> this sound like a good idea! A generic, configurable HC would look
> something like [1] in pseudo code. Using OSGi headers in bundles to
> ensure correct wiring is straight forward, but I'm not sure if there is
> an API to get all currently available capabilities in framework?
>
It's more like can I transitively resolve a running system from:
a) only a code dependency (i.e. I implement some health check API): results
in at resolve I get -> health check implementation -> jaxrs/http servlet
whitebard implemetation
b) I specify @RequireHealthCheck in my main app app where I don't actually
implement any APIs: results in at resolve I get -> health check
implementation -> jaxrs/http servlet whitebard implemetation
:)
I can probably try it out and submit the proper cap&req.
- Ray
> -Georg
>
> [1]
> ...
> private List<String> requiredCapabilitiesAsConfigured;
> ...
> public Result execute() {
> List<String> allCapabilitiesRegisteredInFramework = ???
> List<String> missing = new
> ArrayList<>(requiredCapabilitiesAsConfigured)
> missing.removeAll(allCapabilitiesRegisteredInFramework)
> if(missing.isEmpty()) {
> return new Result(Result.Status.OK, "All capabilities
> available: "+StringUtils.join(requiredCapabilitiesAsConfigured))
> } else {
> return new Result(Result.Status.WARN, "Missing capabilities:
> "+StringUtils.join(missing) + "(configured as required:
> "+StringUtils.join(requiredCapabilitiesAsConfigured)+")")
> }
> }
>
>
> On 2019-01-18 16:17, Raymond Auge wrote:
> > Great!
> >
> > I haven't looked so it might already be done, but I would ask that
> > requirements and capabilities be used so that we can resolve a running
> > system with minimal configuration.
> >
> > I can help if someone explains the pieces to me.
> >
> > - Ray
> >
> > On Fri, Jan 18, 2019 at 10:04 AM Georg Henzler <[email protected]>
> > wrote:
> >
> >> Hi all,
> >>
> >> I have spend quite a bit time to polish the new Felix Health Checks
> >> before the first release:
> >>
> >> * The API has been cleaned up while maintaining backwards
> >> compatibility
> >> for 99% of the checks out in the wild (migration guide will be
> >> provided
> >> in Sling)
> >> * Dependencies have been minimised, api and core core run as soon as
> >> slf4j api and servlet api is available
> >> * The new status TEMPORARILY_UNAVAILABLE allows to distinguish
> >> startup/deployment unavailabilities clearly from other CRITICAL
> >> problems
> >> * General checks have been introduced and polished (that part has
> >> improved quite a bit compared to what it was in Sling): Sys Admins can
> >> quickly add checks (web console by configuration only) for JMX
> >> attributes, requests or add scripts to check arbitrary conditions.
> >> * Servlet Filters have been introduced to a) flexibly track certain
> >> requests by registering dynamic tags and b) cut off certain (or all)
> >> requests with 503 if certain tags have a certain status values.
> >>
> >> See [1] for all tickets solved.
> >>
> >> From my point of view everything is ready for the first release but
> >> feedback is welcome! I plan to create the releases for the modules
> >> annotation, api, core, generalchecks and webconsoleplugin next week.
> >>
> >> Best Regards
> >> Georg
> >>
> >> [1]
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Fixed%20AND%20component%20%3D%20%22Health%20Checks%22
> >>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
