[
https://issues.apache.org/jira/browse/CAMEL-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861152#comment-15861152
]
Roland Huss commented on CAMEL-10795:
-------------------------------------
Looks good to me in general. Some remarks:
* Maybe {{validate()}} is a bit better than {{vaildateOptions()}} ? Since it
might be also that a connection fails even when the options are valid (because
the targeted backend has issues at the moment). Hmm, maybe even 'validate' does
not catch this use case (where the options are valid, but still a connection
test fails). Maybe {{check()}} or {{test()}} does fit better ?
* Should it be possible to provide a aggregate scope like "all" ? If so, then
the result needs to be an aggregation, too, with individual result for each
check.
* If a scope of "connectivity" is provided, but the component can't check the
connectivity because the "parameters" are not valid, shouldn't this be
reflected in the return value, too ?
On a second thought, I'm not sure now whether we should stuff all these use
cases in a single, general purpose method, because I see some quite orthogonal
use cases:
* Validate whether a set of configuration options is syntactically valid
({{validate(Map opts)}})
* Check whether a connection is possible ({{test(Map opts)}}). Valid options
are a prerequisite for this.
* Use {{test()}} it for health-checks. For this use case it would be awesome if
the result could contains also some metrics (e.g. how long the connection took).
still in brainstorming mode ;-)
> PingCheck API
> -------------
>
> Key: CAMEL-10795
> URL: https://issues.apache.org/jira/browse/CAMEL-10795
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: Claus Ibsen
> Fix For: 2.19.0
>
>
> Related to CAMEL-10026 about Health Check API
> We need some way for Camel components to be able to more easily validate if
> they can connect to their remote system.
> And for that the user must configure the Camel component/endpoint accordingly
> with details such as username/password/tokens/ other beans etc.
> How this is done varies from Camel component to component, but most of them
> uses endpoint options.
> So we may want to introduce some interface (whether the name Pingable is a
> good name is up for discussion)
> {code}
> interface Pingable {
> PingResult ping(Map<String, String> config);
> boolean canPing(Map<String, String> config);
> }
> class PingResult {
> private boolean isSuccess();
> private String errorMessage();
> }
> {code}
> This API is just a little suggestion.
> The parameters should ideally be type less, eg Map<String, String> as the
> user configures this in endpoint uris, XML DSL etc. and therefore we should
> be able to do this without having to use Java code per see.
> Also we may want to have canPing as a method to check if the component can
> accept the ping or not. In some cases it may not be able to do the ping.
> For example camel-http component would just require the following information
> in the Map<String, String>
> httpUri=http://myserver/foo/bar
> Where httpUri is the name of the option accordingly to the table at
> https://github.com/apache/camel/blob/master/components/camel-http/src/main/docs/http-component.adoc
> And then it depends on each Camel component how they do the ping check, the
> http component may do a HTTP HEAD or a HTTP GET etc and check the HTTP
> response code etc.
> Notice this is not intended entirely for runtime health check, but for
> validating/testing Camel components can work with the user given
> configuration to connect to the remote system.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
