brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <...@git.apache.org>
Subject [GitHub] brooklyn-server pull request #440: BROOKLYN-345: persist brooklyn.parameters...
Date Tue, 29 Nov 2016 13:39:11 GMT
Github user ahgittin commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/440#discussion_r90009674
  
    --- 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!
    --- End diff --
    
    I think things should be de-aliased when writing to the config map, so config map has
canonical config key names _only_ -- ie it should not be up to `config().get()` to figure
out if any aliases are in effect.
    
    Is this not the case?
    
    Agree if we have `{A: val1, B: val2 }` as flags where `A` and `B` are names/aliases for
a given config key there is ambiguity -- this is possible even with `{A: val1, A: val2 }`.
 I'm not too worried about either of these, fair enough to say it's not guaranteed which is
taken.
    
    BTW good code change to treat the parameter definitions of config keys as the preferred
ones.  The only tweak I might suggest is that if the parameter fields are incomplete they
might be merged with those defined on the type (eg description, default value) so that it
isn't necessary to re-declare them as parameters.


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message