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 <[email protected]>
Date: 2016-09-15T11:16:32Z
more entity-config basic tests (all passing, confirm more combos work)
commit 189677def8af93694c4fac9f828575c51ccc1e85
Author: Alex Heneveld <[email protected]>
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 <[email protected]>
Date: 2016-09-16T08:36:37Z
using new config inheritance evaluation, inserted in one place (entities)
commit 94179834619d0890dde40b7169c788317457215c
Author: Alex Heneveld <[email protected]>
Date: 2016-09-19T16:59:56Z
using new config inheritance evaluation, inserted in several places
commit c701fcb07a4fecb596406734086a6d5a9c79c825
Author: Alex Heneveld <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date: 2016-09-19T23:48:43Z
fix and extend inheritance test
and test/explain mis-reported bug there
commit 3e266e62f535da4e9888d475a96e6e811bd4a1c7
Author: Alex Heneveld <[email protected]>
Date: 2016-09-20T08:48:48Z
logging and tests for config-to-task early resolution
commit 5e2b7d4b5df57b004e1cc7ac12ef8d215ccc51a4
Author: Alex Heneveld <[email protected]>
Date: 2016-09-20T09:21:28Z
sketch better api, remove deprecation, tidy map interfaces
commit 06eca356737a528d8e1806b7f2168ae8b07ebf12
Author: Alex Heneveld <[email protected]>
Date: 2016-09-20T10:24:36Z
promote more things to AbstractConfigMapImpl
commit ddc17d157d6ef4418a9af3883ad9bcd16ca2c383
Author: Alex Heneveld <[email protected]>
Date: 2016-09-20T11:28:18Z
make Location use a ConfigMap to bring it in line with others
commit 8405d8774a0380a99b9dd1fbd2daf7fc15265cb8
Author: Alex Heneveld <[email protected]>
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 <[email protected]>
Date: 2016-09-20T12:44:39Z
camp resolver correctly resolves flags used in subtypes
commit e8d44d5a051dc8dff4d994905b67a15bd6752aa5
Author: Alex Heneveld <[email protected]>
Date: 2016-09-20T14:56:23Z
refactor and tidy config-value classes
commit 914982ea3ce7d9bad2d8ec59a7d33783570a79c1
Author: Alex Heneveld <[email protected]>
Date: 2016-09-20T15:23:36Z
remove a bunch of deprecated config methods
commit 0d655e0503ae1cdf7ad4f95b5321118041bd0592
Author: Alex Heneveld <[email protected]>
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 [email protected] or file a JIRA ticket
with INFRA.
---
