GitHub user ahgittin opened a pull request:
https://github.com/apache/brooklyn-server/pull/480
Config self reference fix
builds on #462 fixing the remaining issues discussed in BROOKLYN-329
immediate eval could be improved yet further but this fixes
scope/resolution issues and in general makes immediate things much more
reliable, as well as fixing recursive references in config settings, and
helping to debug bad task traces
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ahgittin/brooklyn-server
config-self-reference-fix
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/brooklyn-server/pull/480.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 #480
----
commit 667c3dffbe654dfb409a64ab7e2675784c7d7433
Author: Alex Heneveld <[email protected]>
Date: 2016-11-17T15:12:09Z
implement inheritance of config default values
test and code changes to respect the additional inheritance argument added
in the previous request:
resolves https://issues.apache.org/jira/browse/BROOKLYN-267
commit 53ae1c611c736ee572801f840785266690531da9
Author: Alex Heneveld <[email protected]>
Date: 2016-11-24T10:56:46Z
migrate config inheritance to new classes
pioneers use of `readResolve` that actually works brilliantly out of the
box due to xstream
also tidying `BasicConfigInheritance` and adding a placeholder (not used
yet)
for resolving ancestor defaults
includes tests for config inheritance serialization
commit aef2c7c55f854027bc79bf9ec3ada336ff86955f
Author: Alex Heneveld <[email protected]>
Date: 2016-11-24T16:29:21Z
document better config inheritance semantics
commit 2d762c4c9ee4dd4345fe1b4419cf4f52fb8e1ff3
Author: Alex Heneveld <[email protected]>
Date: 2016-11-24T17:34:10Z
uncomment another assertion about inherited config
commit 536fb1a78066d5c1b0f1c3d3337ee8aa89e4f8e5
Author: Alex Heneveld <[email protected]>
Date: 2016-11-29T11:51:57Z
don't use transients as not reset on deserialization
commit 13648d8c7e5c453c62f7d6de67a3681616c4b930
Author: Alex Heneveld <[email protected]>
Date: 2016-12-02T00:46:03Z
PR comments on config defaults
commit 5c6c72136732f1d20e21f217a109db5a7d88b6f1
Author: Alex Heneveld <[email protected]>
Date: 2016-12-02T00:47:16Z
no need for `keepSameInstance` in `RebindOptions` as we have a field
`mementoDir`
commit 944757ce916c3d70f84612ec26a647c1fe3865c2
Author: Alex Heneveld <[email protected]>
Date: 2016-12-02T09:17:01Z
comments on parameter/config inheritance/merging
commit ae0ac1e0ec6b5b054987c909f97fb993705b40ea
Author: Alex Heneveld <[email protected]>
Date: 2016-12-02T13:54:12Z
fix test for taking default from parameter
as per (1) at https://issues.apache.org/jira/browse/BROOKLYN-329
commit 1a6717097caabe13872133c432d158360b0123fb
Author: Alex Heneveld <[email protected]>
Date: 2016-12-02T13:54:50Z
improve methods for retrieving config keys
previously only looked at what was in the map, not what reference keys
might be defined in the container (eg entity)
as per (5) at https://issues.apache.org/jira/browse/BROOKLYN-329
commit 7177662931b7d0109e44f4653a7e09ddfaffbd7b
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T08:53:49Z
fix version reference in config inheritance test
commit cc639c52c28b4337eb4b638bfd4182c775891e50
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T10:03:04Z
need to restrict keys to those present for ssh commands
else we pick up `null` values ... alternatively could take declared and
filter for nulls,
but this change restores the old working behaviour
if ever we need to get default values of keys when passing in this way, we
should revert this and filter null values
commit a2f8b207cc576c350a9a9e9d3431bc8c2df86e8d
Author: Alex Heneveld <[email protected]>
Date: 2016-12-05T10:50:38Z
merge default values in config inheritance
as per (6) at https://issues.apache.org/jira/browse/BROOKLYN-329
(only does it for yaml parameters, but that's a limitation we can live with
i think;
notes included on doing it for java)
also switches to new `fromString` which adjusts the interpretation of
inheritance "none" to be NOT_INHERITED,
with new keyword "never" available if caller really wants NEVER_INHERITED
(this is in keeping with previous changes to the semantics)
commit b66c5966074a564091c3d35a76d2f8fb94d52791
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T10:50:10Z
clean up SpecParameterUnwrappingTest
commit e464d2a6237eb668e9233863ad4108c44acc01a5
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T11:42:48Z
fix merge wrapper semantics to combine parameters not overwrite
commit 4d61ff8f2a0ff785afa9c0fe0437856237d8fe2a
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T15:50:18Z
handle recursive task errors incl self-ref config
address BROOKLYN-329 case (2), where a config key is defined as a function
of itself
detect the endless loop that results and fail with a good message
also better handling in general of endless-loop task failures,
including:
* bail-out logic in Exceptions.collapse to prevent crazy long strings and
traces
* warning whenever active tasks passes N*1000
commit 373ae654a826d1e572a42e2d67fecfbda9e44213
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T16:09:20Z
add (failing) test re config loop and immediate evaluation
commit 42c8c103eb90c9b6a33f99332a820a43118c4647
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T16:26:41Z
better logging and reporting if no entity available for immediate eval
commit f4b22615f3bbe554db08a2c6a9633c4d7caffaff
Author: Alex Heneveld <[email protected]>
Date: 2016-11-17T15:11:14Z
flesh out test cases around non-blocking evaluation
commit 9fe59acfc7c1296303fcc270253417141a005e41
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T22:15:10Z
immediate execution runs in a fake tag allowing context to be evaluated
most new immediate tests now passing, including a new test which detects
recursive config values for immediate;
except we still have:
* cancellations of immediate execution goes too far, and cancels tasks
which are set as values
* task factories still not supported for evaluation
commit 2966283ede9fce959fccfd5a7175ca479b6cda7d
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T22:34:46Z
solve problem with map eval where tasks are cancelled permanently
sets non-transient if a task is requested for a value-resolver
we might want to deprecate that altogether, instead use TaskFactory
so we can cancel things
don't think there will be much leaking because the ValueResolver isn't used
for new tasks,
just for tasks which are set as values -- but we need to keep an eye on
that.
such tasks should be cancelled when the entities are cleaned up.
commit a94af161d21bd56d5738d09415c473eb95a3d41a
Author: Alex Heneveld <[email protected]>
Date: 2016-12-07T00:46:13Z
slow tests moved to integration group
commit dd887dda687cba3ef14207ffef05b2267d512867
Author: Alex Heneveld <[email protected]>
Date: 2016-12-06T22:45:14Z
cleanup, and allow TaskFactory to be supplied as a config and other
ValueResolver input
the TF will create a task which will then be used for evaluation.
much cleaner semantics than setting tasks as values:
tasks evaluate once and remember their result, whereas task factory spawns
a new task each time.
furthermore, the former cannot be interrupted without making the value
_never_ resolvable (which was the case prior to the previous commit)
so it is left running if immediate eval is done, whereas the latter can be
safely cancelled.
----
---
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.
---
