Github user neykov commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/383#issuecomment-72200464
Presently all instantiations of CAMP YAML are done at the AssemblyTemplate
level, no? Even "Add Child" creates an app and then strips it to get the
entity. The same `encounteredCatalogTypes` set is used for the all components
in the YAML so it shouldn't matter how deep a recursive reference is. As for
instantiating entitites within Java code, then this is not applicable as the
fix is for breaking catalog item cycles. It's highly probable that I dind't
fully understand your comments, so feel free to correct my missunderstanding :).
The change improves how standalone catalog items are instantiated. This
only applies when creating an `EntitySpec` from the catalog items directly
(when adding them to the catalog to check the app type, when listing the
catalog items from REST). When instantiating catalog items as part of an
application template the `encounteredCatalogTypes` is already properly
initialized.
Creating a spec out of a catalog item directly was treating the catalog
yaml as an application, starting any exclusion in `encounteredCatalogTypes` one
level below them. If the user was creating catalog items with `id` matching the
`javaType` and there was already a catalog item with the same `symbolicName` in
the catalog (i.e. when updating catalog items) then we would get the following
structure
* new catalog item
* old catalog item
* java type resolved from old catalog item
With the change in place we get:
* new catalog item
* java type resolved from new catalog item
The difference is that now we initialize `encounteredCatalogTypes` in
`BasicBrooklynCatalog` forcing the code to ignore existing catalog items with
the same `id`.
---
Re `tryLoadEntityClass`. With the following in the catalog:
```
brooklyn.catalog:
id: sample.java.Type
libraries:
- http://simple.jar
services:
- type: sample.java.Type
```
and then updaing the catalog with
```
brooklyn.catalog:
id: sample.java.Type
libraries:
- http://invalid-url-or-libraries-missing.jar
services:
- type: sample.java.Type
```
Where the second catalog item doesn't have any `libraries` or they don't
have `sample.java.Type` in them - resolving `sample.java.Type` in the second
catalog item would be done with the `OsgiBrooklynClassLoadingContext` of the
first item, so it would successfully resolve the java class.
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
