brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: Support for external config in catalog definition
Date Tue, 05 Jan 2016 17:36:54 GMT
Hi Ivana,

Tricky - given the first level of yaml parsing is being done in a 
completely different place.

I think that BasicBrooklynCatalog just stores the yaml of the "item" as 
a String, and later will get the brooklyn-camp module to parse it.

---
In BasicBrooklynCatalog, can you just look up the CampYamlParser, and 
use that to parse the relevant values? That would be a similar approach 
as in PR #1112:

mgmt.getConfig().getConfig(CampYamlParser.YAML_PARSER_KEY)

---
I don't think we should have to write another parser. Can you elaborate 
on what you are intending to do with "writing now a small parser", so 
can we just solve that by looking up the CampYamlParser instead?

Aled


On 05/01/2016 17:01, Ivana Yovcheva wrote:
> Hi all,
>
> I'm working on the usage of external config in catalog definition.
>
> Here is an example:
>
> *brooklyn.catalog:*
>
>
>
>
>
>
>
>
>
>
> *  id: mysql  version: 1.0  description: A MySql server  displayName:
> Mysql  iconUrl: classpath:///mysql-logo-110x57.png  itemType: template
> brooklyn.libraries:  - $brooklyn:external(A, B)  item:    services:*
>
>
> *    - type: brooklyn.entity.database.mysql.MySqlNode*
> For the value of *'item' *there is working code that parses the '$brooklyn'
> tag.
> So we are interested in the other keys.
> As there is no recursion for them, the best approach is to parse each value
> and if it contains the tag, to replace it with the object returned from the
> parser or leave it unchanged otherwise.
>
> *Here comes a problem.* *DslParser* is in *brooklyn-camp* module, which
> depends on *brooklyn-core*.
> I need to use it in *BasicBrooklynCatalog *which is in *brooklyn-core* but
> cannot depend on *brooklyn-camp*.
>
> There is similar PR (#1112
> <https://github.com/apache/incubator-brooklyn/pull/1112>) to support
> external config in *BrooklynProperties*, were there is no recursion, but it
> is used from classes in the* brooklyn-camp* module.
>
>
> One approach is to write similar parser out of the camp module, but this
> means too much repetitive code.
>
> The other is to move *DslParser *out of *brooklyn-camp*, which looks the
> best for the future.
>
> I am writing now a small parser for the catalog only in order to introduce
> the feature and we can remove it after refactoring as moving *DslParser *is
> bigger task.
>
> Could you give some advice or share opinion?
>
> Best,
> Ivana
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message