Github user neykov commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/174#discussion_r65498168
--- Diff:
core/src/test/java/org/apache/brooklyn/core/entity/EntityConfigTest.java ---
@@ -208,8 +210,18 @@ public void testGetConfigMapWithExplicitMap() throws
Exception {
assertEquals(entity.config().getNonBlocking(TestEntity.CONF_MAP_THING.subKey("mysub")).get(),
"myval");
}
- @Test
- public void testGetConfigNonBlocking() throws Exception {
+ // TODO This now fails because the task has been cancelled, in
entity.config().get().
+ // But it used to pass (e.g. with commit
56fcc1632ea4f5ac7f4136a7e04fabf501337540).
+ // It failed after the rename of CONF_MAP_THING_OBJ to
CONF_MAP_OBJ_THING, which
+ // suggests there was an underlying problem that was masked by the
unfortunate naming
+ // of the previous "test.confMapThing.obj".
+ //
+ // Presumably an earlier call to task.get() timed out, causing it to
cancel the task?
+ // I (Aled) question whether we want to support passing a task (rather
than a
+ // DeferredSupplier or TaskFactory, for example). Our
EntitySpec.configure is overloaded
+ // to take a Task, but that feels wrong!?
--- End diff --
Passing Tasks as config keys makes sense for me (same as passing a future).
Creating a task to compute some value and passing it to an entity is a common
thing in Brooklyn.
---
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.
---
