Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rule file provider
JSON
andYAML
filesDELETE
event bug inFolderObserver
Description
The primary task of this PR is to provide file-based
YAML
andJSON
rules. It supports multiple rules in one file if they are supplied within an array, which means enclosed in[
and]
and separated with comma.This PR is very loosely coupled to #4591 in that they are both split out as PRs from the same "work branch", and this PR use the
AbstractJacksonYAMLParser
introduced in #4591. TheFolderObserver
file watcherDELETE
fix has been included here, since it was discovered after #4591 was submitted.There is one issue that might need to be discussed, and that is the location to look for the
YAML
andJSON
files. There are two "obvious candidates",conf/automation/rules
andconf/rules
. The latter is the folder already in use for Rules DSL files, while the former isn't currently used (or automatically created when OH is installed). In either case, some minor changes to the documentation should be made as well, but it's hard to write that until the final location has been decided.Currently, this PR uses
conf/rules
, but that's very easy to change. From a user's perspective, this might be the most logical, as they are still rules, although the format is different. It doesn't seem like this causes any conflicts, but a debug log message is created both from the Rules DSL parser (that it ignores the.yaml
or.json
file) and from theAbstractFileProvider
that it doesn't have a parser for.rules
files. None of these are shown by default. The involved classes could be modified to not log these cases, as they are expected, but both are "generic in nature" and introducing exceptions to concrete file extensions doesn't really "fit".If
conf/automation/rules
are used instead, the "conflict" with two parsers monitoring the same folder would be avoided, but it might be more confusing for the end user to have to place the rule files in two different locations. It should also be considered if this folder should be created when the installation is set up, like with many of the other folders.It should also be mentioned that the documentation currently claims support for
JSON
based rules, but no evidence that this exists, or has existed in previous versions, has been found in the code:If this actually is wrong, the documentation should be corrected.