4.x: Declarative features configuration alignment and documentation #10394
Conversation
Update to declarative features, to honor configuration overrides where reasonable Update to declarative documentation to describe approach to configuration
oracle-contributor-agreement
bot
added
the
OCA Verified
…n the module readme Updated configuration for HTTP example
|
|
||
| 1. Configuration key may be explicitly defined in an annotation to override the rules below | ||
| 2. The root configuration node for overriding annotation values is `type-config` | ||
| 3. Second level configuration node is the fully qualified class name of the annotated type (i.e. `com.example.MyType`) |
There was a problem hiding this comment.
So in Java properties format would this look like type-config.com.foo.Bar.blat.frob? How do I know what the class name is?
There was a problem hiding this comment.
you do not need to know - the key is created by the component. As this is a fully qualified class name, there cannot be duplicate cases.
You could theoretically factor a duplicate key, but you would have to use package name starting with a capital letter, and class name starting with a lower case one - we do not need to support this
| type-config: | ||
| "com.example.MyType": | ||
| server: | ||
| listener: "admin" # override socket name |
There was a problem hiding this comment.
(So in Java properties format this is type-config.com.example.MyType.server.listener = admin. Is that OK?
There was a problem hiding this comment.
Yes that is the key that would be used
Update of FT features, added common configuration for name and
enabledUpdate to declarative features, to honor configuration overrides where reasonable Update to declarative documentation to describe approach to configuration