Hi Ray,
so your suggestion is more about referring to a capability like
"org.apache.felix.healthcheck" by using requirements in other bundles
than writing a health check that ensures the framework provides a
certain non-healthcheck-related capability.
I can probably try it out and submit the proper cap&req.
that would be great!
-Georg
On 2019-01-18 17:28, Raymond Auge wrote:
On Fri, Jan 18, 2019 at 11:08 AM Georg Henzler <fe...@ghenzler.de>
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
:)
- 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 <fe...@ghenzler.de>
> 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
>>
