brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aledsage <...@git.apache.org>
Subject [GitHub] brooklyn-server pull request #612: BROOKLYN-460: Brooklyn Camp syntax for ad...
Date Fri, 31 Mar 2017 11:37:26 GMT
Github user aledsage commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/612#discussion_r109141795
  
    --- Diff: camp/camp-brooklyn/src/main/java/org/apache/brooklyn/camp/brooklyn/spi/creation/BrooklynComponentTemplateResolver.java
---
    @@ -257,6 +257,7 @@ public boolean canResolve() {
             new BrooklynEntityDecorationResolver.EnricherSpecResolver(yamlLoader).decorate(spec,
attrs, encounteredRegisteredTypeIds);
             new BrooklynEntityDecorationResolver.InitializerResolver(yamlLoader).decorate(spec,
attrs, encounteredRegisteredTypeIds);
             new BrooklynEntityDecorationResolver.SpecParameterResolver(yamlLoader).decorate(spec,
attrs, encounteredRegisteredTypeIds);
    +        new BrooklynEntityDecorationResolver.TagsResolver(yamlLoader).decorate(spec,
attrs, encounteredRegisteredTypeIds);
    --- End diff --
    
    Thanks @neykov - makes sense. However, a much bigger topic is how we really should be
defining effectors/feeds in yaml. To me, the `brooklyn.initializers` feels like a powerful
hack - re-using a generic feature to add things that are fundamental to blueprints. I think
it's confusing for users to have to use `brooklyn.initializers` rather than us having first-class
`brooklyn.effectors`. But let's not discuss that here - it can be a dev@brooklyn discussion
when we're ready!


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

Mime
View raw message