New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BACKPORT] Add ConfigRecognizer API #17093
[BACKPORT] Add ConfigRecognizer API #17093
Conversation
This commit introduces the ConfigRecognition API that is meant to recognize if a provided declarative configuration is recognized by the rules defined in a given implementation. The main use case for this implementation is to recognize member, client and failover client XML and YAML configurations just by looking into the content of the configuration, without building any actual configuration. Along with the API the following three implementations are added: - MemberConfigRecognizer for recognizing member XML and YAML configurations - ClientConfigRecognizer for recognizing client XML and YAML configurations - ClientFailoverConfigRecognizer for recognizing failover client XML and YAML configurations All the three are extensible with custom recognizers so that even those configurations can be recognized that would otherwise remain unrecognized with the built-in set of recognizers that recognizes XML and YAML configurations by checking the root node in the provided configuration. The API recognizes configuration provided in InputStreams only, while the ConfigBuilder implementations can be built from files defined by their location and URLs too. The reason for lacking the support for these two options is that both are easy to convert to InputStreams and that handling errors caused by non-existing resources, missing privileges etc should be handled outside of this API with potentially having more contextual information. The built-in implementations honour parse errors with unrecognized configuration. The reason is that the provided InputStream can be tested both for XML and YAML configuration and at least one is expected to lead to parse errors. Implements hazelcast#16866 (cherry picked from commit 9457ddc)
/* | ||
* Copyright (c) 2008-2020, Hazelcast, Inc. All Rights Reserved. | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't be the community license? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For OS we kept apache, community is for integration modules mostly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Client only
Almost 1:1 backport of #16958
The only resolved conflict is in
IOUtil
in an import.This commit introduces the
ConfigRecognition
API that is meant torecognize if a provided declarative configuration is recognized by the
rules defined in a given implementation. The main use case for this
implementation is to recognize member, client and failover client XML
and YAML configurations just by looking into the content of the
configuration, without building any actual configuration.
Along with the API the following three implementations are added:
MemberConfigRecognizer
for recognizing member XML and YAMLconfigurations
ClientConfigRecognizer
for recognizing client XML and YAMLconfigurations
ClientFailoverConfigRecognizer
for recognizing failover client XML andYAML configurations
All the three are extensible with custom recognizers so that even those
configurations can be recognized that would otherwise remain
unrecognized with the built-in set of recognizers that recognizes XML
and YAML configurations by checking the root node in the provided
configuration.
The API recognizes configuration provided in InputStreams only, while
the ConfigBuilder implementations can be built from files defined by
their location and URLs too. The reason for lacking the support for
these two options is that both are easy to convert to InputStreams and
that handling errors caused by non-existing resources, missing
privileges etc should be handled outside of this API with potentially
having more contextual information.
The built-in implementations honor parse errors with unrecognized
configuration. The reason is that the provided InputStream can be tested
both for XML and YAML configuration and at least one is expected to
lead to parse errors.
Implements #16866