GitHub user ahgittin opened a pull request:

    https://github.com/apache/brooklyn-server/pull/340

    ConfigMap refactor, respecting inheritance

    As discussed on #281, there were some severe limitations in the way we 
handled config and inheritance.  This addresses many of those, and others, 
including:
    
    * A distinction between `NOT_REINHERITED` and `NEVER_INHERITED`
    * Lift evaluation of inheritance so callers don't repeat code
    * Bringing `Location` config in line with `Entity` and `EntityAdjunct`
    * Clarification of what is returned by "get all" methods in an inherited, 
merging, resolving, coercing world
    * REST API and other methods no longer show dis-inherited config
    * DSL components are resolved against the ancestor who declares the value
    * API supports accessing which ancestor declares a value, for contexts 
which need e.g. to resolve a URL in the bundle context of a catalog item
    
    This fixes some broken tests and removes a whole lot of TODO comments 
(whilst only adding a few!).  It does come at a cost of complexity (especially 
in the evaluation of inherited config; however since *all* tests pass it 
doesn't need super-close study at this point, I think).  I'm convinced it's 
necessary complexity unless we move away from this style of inheritance (which 
in time we might well be able to do!).
    
    There are a few areas where backwards compatibility is impacted which will 
need to go into the release notes:
    
    * Config is now resolved against the ancestor where it is defined, e.g. 
attributeWhenReady;
        TODO do we need a way to specify that config should be resolved against 
the resolver?
    * `ConfigMap.submap` is no longer supported for entity config; findKeys has 
been introduced, and the method is available on the main sub-interfaces where 
it was used
    * Location config is treated like Entities and Adjuncts; it respects 
inheritance
        * as a consequence of this, some persisted usage information is no 
longer available
    
    (The biggest of these is Location config changes now needing to go through 
the right API; you can no longer just edit the bag.  I think I've caught most 
of these but test with care!)

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ahgittin/brooklyn-server config-map-refactor

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/340.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #340
    
----
commit 759d67e22b7841e4c2c138c341eda0b299b09498
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-15T11:16:32Z

    more entity-config basic tests (all passing, confirm more combos work)

commit 189677def8af93694c4fac9f828575c51ccc1e85
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-15T23:19:51Z

    introduce inheritance contexts so ConfigKey is not opinionated about type v 
runtime inheritance
    (that's a choice Brooklyn makes about how to use config keys)

commit 29706561bfba35953deb420d478ae0cb9035863a
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-16T08:36:37Z

    using new config inheritance evaluation, inserted in one place (entities)

commit 94179834619d0890dde40b7169c788317457215c
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-19T16:59:56Z

    using new config inheritance evaluation, inserted in several places

commit c701fcb07a4fecb596406734086a6d5a9c79c825
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-19T17:31:14Z

    migrate all ConfigInheritance modes to new values
    
    (the old ones are still defined, deprecated, and we've confirmed both paths 
work)

commit 8847b2eed525f23080e8741ed5d9ba7119507534
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-19T22:11:11Z

    change impl of EntityConfigMap to not cache inherited
    
    fix tests, and misc other more fixes and notes

commit 9b9f51d3d60d11324cedb42a1517364aed259054
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-19T23:48:43Z

    fix and extend inheritance test
    
    and test/explain mis-reported bug there

commit 3e266e62f535da4e9888d475a96e6e811bd4a1c7
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T08:48:48Z

    logging and tests for config-to-task early resolution

commit 5e2b7d4b5df57b004e1cc7ac12ef8d215ccc51a4
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T09:21:28Z

    sketch better api, remove deprecation, tidy map interfaces

commit 06eca356737a528d8e1806b7f2168ae8b07ebf12
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T10:24:36Z

    promote more things to AbstractConfigMapImpl

commit ddc17d157d6ef4418a9af3883ad9bcd16ca2c383
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T11:28:18Z

    make Location use a ConfigMap to bring it in line with others

commit 8405d8774a0380a99b9dd1fbd2daf7fc15265cb8
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T12:07:22Z

    share code in AbstractConfigurationSupport, and fix location config issues 
from previous
    
    support clearing, prevent writes to config bag, and allow coercion from 
class names

commit bcd8b26a1eb3793e3b0fb036f1fe5c75aa6b6987
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T12:44:39Z

    camp resolver correctly resolves flags used in subtypes

commit e8d44d5a051dc8dff4d994905b67a15bd6752aa5
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T14:56:23Z

    refactor and tidy config-value classes

commit 914982ea3ce7d9bad2d8ec59a7d33783570a79c1
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T15:23:36Z

    remove a bunch of deprecated config methods

commit 0d655e0503ae1cdf7ad4f95b5321118041bd0592
Author: Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Date:   2016-09-20T15:43:43Z

    cleaner config / config-map api understanding inheritance
    
    * Config is now resolved against the ancestor where it is defined, e.g. 
attributeWhenReady;
      (but do we need a way to specify that config should be resolved against 
the resolver?)
    * submap is no longer supported for entity config; findKeys has been 
introduced
    * many methods tidied and deprecated

----


---
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.
---

Reply via email to