Skip to content

Improve Brooklyn-management of OSGi-already-managed bundles#842

Merged
asfgit merged 8 commits intoapache:masterfrom
ahgittin:bundles-brooklyn-import-osgi-already-managed
Sep 26, 2017
Merged

Improve Brooklyn-management of OSGi-already-managed bundles#842
asfgit merged 8 commits intoapache:masterfrom
ahgittin:bundles-brooklyn-import-osgi-already-managed

Conversation

@ahgittin
Copy link
Copy Markdown
Contributor

Previously could claim it was already installed but not brooklyn-manage it.

Now it is much smarter about checking whether what is being supplied now (by reference or by contents) is an exact match and if so, don't uninstall and reinstall it.

Some annoying issues fixing tests due to how karaf/java deals with target/classes/ bundles in dev, but tests are all working too now.

NB this requires #810 due to conflicts in osgi bundle removal semantics

take the URL from the existing osgi-installed bundle.
much better logging.
needed for tests now that we do more with bundles supplied in brooklyn.libraries
makes behaviour consistent with dist behaviour regarding karaf urls
@tbouron tbouron mentioned this pull request Sep 25, 2017
Copy link
Copy Markdown
Contributor

@geomacy geomacy left a comment

Choose a reason for hiding this comment

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

Broadly this looks good to me, a couple of trivial comments; but it is pretty complex code and I'm sure there could be subtleties lurking in there that I have missed.

} else {
// if bundle is not brooklyn-managed we want to make it be so
// and for that we need to find a URL.
// some things declare usable locations, though these might be maven and
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

text ends just with and - did you mean to put something more?

result.metadata = new BasicManagedBundle(installedBundle.get().getSymbolicName(), installedBundle.get().getVersion().toString(),
suppliedKnownBundleMetadata!=null ? suppliedKnownBundleMetadata.getUrl() : null);

assert zipIn!=null || suppliedKnownBundleMetadata.getUrl()!=null : "should have found a stream or inferred a URL";
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do you really mean to use normal Java assert here? If it's worth asserting here is it not worth asserting normally at run time ie. without having to configure JVM -ea?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

the assertion was more for a person reading it

// get a handle on the zip file (although we could skip if not doing persistence - but that feels even worse than this!)
try {
url = Strings.removeFromStart(url, "system:");
File zipTemp = new BundleMaker(ResourceUtils.create()).createJarFromClasspathDir(url);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I take it that createJarFromClasspathDir works ok in this case, where the url will start with file:.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yep, ClassLoaderUtilsTest depends on this and it passes. pretty cool.

@ahgittin
Copy link
Copy Markdown
Contributor Author

all addressed -- thx @geomacy, merging

@asfgit asfgit merged commit 9a01418 into apache:master Sep 26, 2017
asfgit pushed a commit that referenced this pull request Sep 26, 2017
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.

3 participants