Github user ahgittin commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/440#discussion_r90607451
--- Diff:
camp/camp-brooklyn/src/main/java/org/apache/brooklyn/camp/brooklyn/spi/creation/BrooklynComponentTemplateResolver.java
---
@@ -374,15 +374,45 @@ protected ConfigInheritance
getDefaultConfigInheritance() {
* Searches for config keys in the type, additional interfaces and the
implementation (if specified)
*/
private Collection<FlagConfigKeyAndValueRecord>
findAllFlagsAndConfigKeyValues(EntitySpec<?> spec, ConfigBag bagFlags) {
+ // Matches the bagFlags against the names used in
brooklyn.parameters, entity configKeys
+ // and entity fields with `@SetFromFlag`.
+ //
+ // Returns all config keys / flags that match things in bagFlags,
including duplicates.
+ // For example, if a configKey in Java is re-declared in YAML
`brooklyn.parameters`,
+ // then we'll get two records.
+ //
+ // Make some effort to have these returned in the right order.
That is very important
+ // because they are added to the `EntitySpec.configure(key, val)`.
If there is already
+ // a key in `EntitySpec.config`, then the put will replace the
value and leave the key
+ // as-is (so the default-value and description of the key will
remain as whatever the
+ // first put said).
+
+ // TODO We should remove duplicates, rather than just doing the
`put` multiple times,
+ // relying on ordering. We should also respect the ordered
returned by
+ // EntityDynamicType.getConfigKeys, which is much better (it
respects `BasicConfigKeyOverwriting`
+ // etc).
+ //
+ // However, that is hard/fiddly because of the way a config key
can be referenced by
+ // its real name or flag-name.
+ //
+ // I wonder if this is fundamentally broken (and I really do
dislike our informal use
+ // of aliases). Consider a configKey with name A and alias B. The
bagFlags could have
+ // {A: val1, B: val2}. There is no formal definition of which
takes precedence. We'll add
+ // both to the entity's configBag, without any warning - it's up
to the `config().get()`
+ // method to then figure out what to do. It gets worse if there is
also a ConfigKey with
+ // name "B" the "val2" then applies to both!
+ //
+ // I plan to propose a change on dev@brooklyn, to replace
`@SetFromFlag`!
+
Set<FlagConfigKeyAndValueRecord> allKeys = MutableSet.of();
--- End diff --
agree -- applying in #462
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
