brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aledsage <>
Subject [GitHub] brooklyn-server pull request #734: Support ConfigKey deprecated names
Date Wed, 28 Jun 2017 16:07:53 GMT
Github user aledsage commented on a diff in the pull request:
    --- Diff: core/src/main/java/org/apache/brooklyn/core/location/ ---
    @@ -215,6 +216,16 @@ public AbstractLocation configure(Map<?,?> properties) {
    +        // allow config keys to be set by name (or deprecated name)
    +        //
    +        // Aled thinks it would be sensible to remove the consumed flags below (i.e.
properties = ...).
    +        // However, that caused ClockerDynamicLocationPatternTest to fail because there
is a field of 
    +        // StubContainerLocation annotated with `@SetFromFlag("owner")`, as well as a
config key with 
    --- End diff --
    Not certain - I deleted the test that used it in #728. My concern is whether that test
highlighted that we're supposed to be supporting such madness!
    @ahgittin's comment was: "if it's not too hard to log a warning wherever we rely on it,
however, that would be ideal. if that's not easy then fine to abandon.".
    It's probably tricky to log.warn on it reliably (because `FlagUtils.setFieldsFromFlagsWithBag`
and `FlagUtils.setAllConfigKeys` also does logic for setting config, so we can't easily tell
how it's using the key).
    We could try adding some new code, e.g. in `EntityDynamicType`, to detect it, and warn
(or even fail) if we see the name being used in multiple places. I suggest we do that separately
from this PR, and I suggest that we fail-fast.
    I'd be happy with abandoning - i.e. change it to what I proposed in the comment, to not
pass the used properties to `FlagUtils.setFieldsFromFlagsWithBag` or `FlagUtils.setAllConfigKeys`.
    I'll go with abandoning, unless anyone feels strongly to the contrary?

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

View raw message