We could avoid the need for clients to explicily track child/member 
updates, but we can't eliminate the need for them to listen to 
sensor-change events in bucket-from-attribute use cases. The (client) 
subscription code in the unit test would still be required as-is.
On 14/03/2014 17:11, Aled Sage wrote:
> In core/src/main/java/brooklyn/entity/group/DynamicMultiGroupImpl.java:
>
>> +     * Convenience factory method for the common use-case of providing entities from another entity's children.
>> +     * @see DynamicMultiGroup#ENTITY_PROVIDER
>> +     */
>> +    public static Iterable<Entity> iterableForChildren(final Entity parent) {
>> +        return new Iterable<Entity>() {
>> +            public Iterator<Entity> iterator() { return parent.getChildren().iterator(); }
>> +        };
>> +    }
>> +
>> +    /**
>> +     * Convenience factory method for the common use-case of providing entities from a group's members.
>> +     * @see DynamicMultiGroup#ENTITY_PROVIDER
>> +     */
>> +    public static Iterable<Entity> iterableForMembers(final Group group) {
>> +        return new Iterable<Entity>() {
>> +            public Iterator<Entity> iterator() { return group.getMembers().iterator(); }
>
> I also wonder about a lower-level config for the entities (i.e. how to
> push the subscription/listener code into |DynamicMultiGroup|). It could
> have config for a |Predicate<? super Entity>| - it could listen to /all/
> entities, similar to how |DynamicGroup| does it. Let's discuss in person...
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/brooklyncentral/brooklyn/pull/1247/files#r10616909>.
>