[
https://issues.apache.org/jira/browse/BROOKLYN-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946879#comment-15946879
]
ASF GitHub Bot commented on BROOKLYN-460:
-----------------------------------------
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/612
@bostko (cc @tbouron) Thinking about this more, I'm not sure what types we
should support for tags. Maybe accepting any object is a bad idea, as it might
make subsequent features harder to support (e.g. support for looking up /
processing tags).
On the other hand, locking down the types to be just strings without a good
reason seems too extreme.
Looking at the REST api
(`org.apache.brooklyn.rest.resources.EntityResource.listTags()`), it turns the
tags into json via the standard mechanism. It can therefore handle non-string
types. if you use something that does not have a good json representation, then
it becomes a lot less useful. But arguably that's the user's problem
(presumably they had a reason for putting the object in the tags in the first
place).
> Brooklyn Camp syntax for adding tags to an entity spec
> ------------------------------------------------------
>
> Key: BROOKLYN-460
> URL: https://issues.apache.org/jira/browse/BROOKLYN-460
> Project: Brooklyn
> Issue Type: New Feature
> Reporter: Valentin Aitken
> Priority: Minor
>
> Current requirement is to be able to supply String tags in an entity spec in
> YAML so it can be then retrieved via REST API with {{GET
> /v1/applications/<appId>/entities/<entityId>/tags}}.
> Example usage in a YAML blueprint:
> {noformat}
> services:
> - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
> brooklyn.tags:
> - tag1
> - tag2
> {noformat}
> Please shout if you have further requirements for {{brooklyn.tags}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
