Skip to content

Conversation

@ahgittin
Copy link
Contributor

@ahgittin ahgittin commented Oct 5, 2017

just looking at logs and tidying up stuff that is wrong or misleading

have done one so far but i think there are others. best hold off reviewing until all done.

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

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

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?

* @param item Catalog item to remove
* @deprecated since 0.13.0 remove bundles
*/
@Deprecated
Copy link
Member

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

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.

* @param item Catalog item to remove
* @deprecated since 0.13.0 remove bundles
*/
@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?

*
* @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

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

* 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

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

@tbouron
Copy link
Member

tbouron commented Nov 22, 2017

@ahgittin Do you think you can look at the comments above?

@tbouron
Copy link
Member

tbouron commented Aug 30, 2018

@ahgittin Any news on this PR?

@nakomis
Copy link
Contributor

nakomis commented Nov 26, 2019

@ahgittin Can you take a look at this please to see if it is still relevant, and address the comments above if appropriate

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants