BROOKLYN-248: fix location displayName inheritance

[aledsage]

No description provided.

[aledsage]

DO NOT MERGE: although this fixes it for the location test case, it breaks the expected behaviour for locations (see failing jenkins test).

[aledsage]

STILL DO NOT MERGE. I've added more test cases, and reverted the change to CampResolver, because that broke things for entities. But the new tests for a app catalog type extending an existing catalog type fail (and same for locations): it uses the name from the super-type.

[aledsage]

Good to review and merge now (assuming jenkins doesn't find any problems).

[johnmccabe]

I pulled and built a few minutes ago and tried with this catalog:

brooklyn.catalog:
  version: 0.1.2
  items:
  - id: loc-common-base
    name: Base Location
    itemType: location
    item:
      type: localhost
      brooklyn.config:
        privateKeyFile: some common private key file
        privateKeyPassphrase: password
  - id: loc-based-on-common-base
    name: Derived Location
    itemType: location
    item:
      type: loc-common-base
      brooklyn.config:
        user: user-who-inherits-private-key-values
        password: password

And I still see both locations loc-common-base and loc-common-base display with the name Base Location

I also tried adding displayName: XXXX Location to each in brooklyn.config but see the same behaviour.

On a slight tangent, building up locations from other locations lends itself to adding base locations that aren't useable by themselves, for example a base that only sets common private keys - currently those building-block locs show up in the list of locations via the jsgui - it'd be nice to have some way of flagging whether a location gets presented to a user in the UI - either a param or naming convention. Worth considering as a future enhancement?

[neykov]

LGTM, merging.

[neykov]

oops, just saw @johnmccabe's comment. Can you retest as this was updated minutes ago as well. Tests suggest your case should be working.

[aledsage]

@johnmccabe your example works for me when I build and run brooklyn locally. I don't have any files not committed or anything like that.

[johnmccabe]

@aledsage I've deleted my PR branch and am rebuilding again (I'd rebuilt earlier to sanity check my observations... third time lucky)

[johnmccabe]

@aledsage looks like something messed up my side... it works as expected now.

Previously I was deleting then pulling the pr into a branch on brooklyn-server, doing a mvn clean install both there and brooklyn-dist.

This time I deleting the pr branch and pulled it again, and instead built from the uber brooklyn project.

Sorry for the false alarm.

[johnmccabe]

LGTM 👍

[neykov]

thanks @johnmccabe, merging.