Github user neykov commented on a diff in the pull request:
https://github.com/apache/incubator-brooklyn/pull/1017#discussion_r44756034
--- Diff:
core/src/main/java/org/apache/brooklyn/core/catalog/internal/CatalogUtils.java
---
@@ -85,16 +89,23 @@ public static BrooklynClassLoadingContext
getClassLoadingContext(Entity entity)
}
public static BrooklynClassLoadingContext
newClassLoadingContext(@Nullable ManagementContext mgmt, String catalogItemId,
Collection<? extends OsgiBundleWithUrl> libraries) {
+ return newClassLoadingContext(mgmt, catalogItemId, libraries,
null);
+ }
+
+ public static BrooklynClassLoadingContext
newClassLoadingContext(@Nullable ManagementContext mgmt, String catalogItemId,
Collection<? extends OsgiBundleWithUrl> libraries, BrooklynClassLoadingContext
loader) {
BrooklynClassLoadingContextSequential result = new
BrooklynClassLoadingContextSequential(mgmt);
if (libraries!=null && !libraries.isEmpty()) {
result.add(new OsgiBrooklynClassLoadingContext(mgmt,
catalogItemId, libraries));
}
- BrooklynClassLoadingContext loader =
BrooklynLoaderTracker.getLoader();
- if (loader != null) {
+ if (loader !=null) {
--- End diff --
Shouldn't be allowed to stack loaders. A new loader barrier starts at a
catalog item and the same loader is used for all types in the item, including
specs referenced in URLs.
A loader delegates to a single item's osgi bundles, falling back to the
catalog class loader. The root application loader uses only the catalog class
loader.
I believe that even adding the thread local loader is wrong (in the sense
that shouldn't be needed, but added just in case).
---
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.
---
