brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-49) Catalogue should be persisted and used when rebinding
Date Fri, 19 Sep 2014 15:20:35 GMT


ASF GitHub Bot commented on BROOKLYN-49:

Github user aledsage commented on a diff in the pull request:
    --- Diff: core/src/main/java/brooklyn/catalog/internal/ ---
    @@ -18,67 +18,92 @@
     package brooklyn.catalog.internal;
    +import java.util.Map;
    +import java.util.Set;
     import javax.annotation.Nonnull;
     import javax.annotation.Nullable;
    +import brooklyn.basic.AbstractBrooklynObject;
     import brooklyn.catalog.CatalogItem;
     import brooklyn.catalog.internal.BasicBrooklynCatalog.BrooklynLoaderTracker;
    +import brooklyn.entity.rebind.BasicCatalogItemRebindSupport;
    +import brooklyn.entity.rebind.RebindSupport;
    +import brooklyn.mementos.CatalogItemMemento;
    +import brooklyn.util.flags.FlagUtils;
    +import brooklyn.util.flags.SetFromFlag;
    -public abstract class CatalogItemDtoAbstract<T,SpecT> implements CatalogItem<T,SpecT>
    +public abstract class CatalogItemDtoAbstract<T, SpecT> extends AbstractBrooklynObject
implements CatalogItem<T, SpecT> {
         // TODO are ID and registeredType the same?
    -    String id;
    -    String registeredType;
    -    String javaType;
    -    String name;
    -    String description;
    -    String iconUrl;
    -    String version;
    -    CatalogLibrariesDto libraries;
    -    String planYaml;
    +    @SetFromFlag Set<Object> tags = Sets.newLinkedHashSet();
    --- End diff --
    I question whether there is a benefit having `CatalogItemDto` extend `CatalogItem` - i.e.
should anyone accessing this code ever see the DTOs or only the domain objects (DOs)? So does
this just make it more complicated?
    I did wonder if `CatalogItemDtoAbstract` is serving almost the same purpose as `CatalogItemMemento`,
but I think it is different: the former is for deserializing/serializing the catalog.xml,
while the latter is for persisted state. Currently they have different formats but perhaps
they should converge!

> Catalogue should be persisted and used when rebinding
> -----------------------------------------------------
>                 Key: BROOKLYN-49
>                 URL:
>             Project: Brooklyn
>          Issue Type: Improvement
>            Reporter: Sam Corbett
>            Assignee: Sam Corbett
> Proposal:
> The catalogue, consisting of application templates, entities, policies and 'configuration'
(whose purpose is unknown to me and is unused in general), will be persisted to a `catalog`
directory alongside enrichers, entities, locations, nodes, plane and policies. Location definitions
(that are conceptually linked but are unrelated in code) will be stored too.
> Modes of operation:
> * If persistence if disabled load the default catalogue;
> * If persistence is enabled but there is no persisted catalogue (i.e. the server is running
for the first time) then load the default catalogue;
> * Otherwise load the persisted catalogue. Do _not_ load the default catalogue. 

This message was sent by Atlassian JIRA

View raw message