Skip to content

[WIP] clean up startup logging around catalog #856

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ahgittin wants to merge 1 commit into
base: master
Choose a base branch
from
+13 −4
Open

[WIP] clean up startup logging around catalog #856

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 13 additions & 4 deletions core/src/main/java/org/apache/brooklyn/core/catalog/internal/CatalogBundleLoader.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,8 +103,8 @@ private TemporaryInternalScanResult scanForCatalogInternal(Bundle bundle, boolea
this.managementContext.getCatalog().addTypesFromBundleBom(bomText, mb, force, result.mapOfNewToReplaced);
if (validate) {
Set<RegisteredType> matches = MutableSet.copyOf(this.managementContext.getTypeRegistry().getMatching(RegisteredTypePredicates.containingBundle(mb.getVersionedName())));
if (!(matches.containsAll(result.mapOfNewToReplaced.keySet()) && result.mapOfNewToReplaced.keySet().containsAll(matches))) {
// sanity check
if (matches.size()!=result.mapOfNewToReplaced.size()) {
Copy link
Member

@tbouron tbouron Oct 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid this will be too loose: the 2 sets have the same size but we don't know if the items are "the same", i.e. same symbolicName and version.

Could we have a middle ground here? Something like looping over each items in result.mapOfNewToReplaced, checking if matches contains one with the same symbolicName and version. Those fields should be resolved and would provide sufficient equality in this case. WDYT?

Copy link
Contributor

@aledsage aledsage Nov 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ahgittin can you explain more the purpose/context of this check, and why you only want to log.warn if the sizes are different?

I recall seeing such warnings in the log when I suspect we shouldn't have, so think you're right to guard against it better.

For @tbouron's suggestion of checking the symbolicName:version, that makes sense - or does this get called a lot or with really big things so performance matters?

// sanity check - should have same types, except result keys might not be fully resolved, so don't do set equality
LOG.warn("Discrepancy in list of Brooklyn items found for "+mb.getVersionedName()+": "+
"installer said "+result.mapOfNewToReplaced.keySet()+" ("+result.mapOfNewToReplaced.keySet().size()+") "+
"but registry search found "+matches+" ("+matches.size()+")");
Expand All @@ -128,10 +128,12 @@ private TemporaryInternalScanResult scanForCatalogInternal(Bundle bundle, boolea
}

/**
* Remove the given items from the catalog.
* Remove the given item from the catalog.
*
* @param item Catalog items to remove
* @param item Catalog item to remove
* @deprecated since 0.13.0 remove bundles
Copy link
Member

@tbouron tbouron Oct 13, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be updated to 1.0.0

*/
@Deprecated
Copy link
Member

@tbouron tbouron Oct 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not seem in the scope of this PR. Also not sure why deprecating it?

Copy link
Contributor

@aledsage aledsage Nov 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like code is not called, and it's in an internal package. Therefore I'm ahppy with it being deprecated (or even deleted immediately). Same for below.

public void removeFromCatalog(CatalogItem<?, ?> item) {
try {
this.managementContext.getCatalog().deleteCatalogItem(item.getSymbolicName(), item.getVersion());
Expand All @@ -143,6 +145,13 @@ public void removeFromCatalog(CatalogItem<?, ?> item) {
}
}

/**
* Remove the given item from the catalog.
*
* @param item Catalog item to remove
* @deprecated since 0.13.0 remove bundles
Copy link
Member

@tbouron tbouron Oct 13, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be updated to 1.0.0

*/
@Deprecated
Copy link
Member

@tbouron tbouron Oct 6, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not seem in the scope of this PR. Also not sure why deprecating it?

public void removeFromCatalog(VersionedName n) {
((ManagementContextInternal)managementContext).getOsgiManager().get().uninstallCatalogItemsFromBundle(n);
}
Expand Down