search

knopflerfish / knopflerfish.org

Knopflerfish OSGi Service Platform. OSGi run-time container and SDK source code repo
http://www.knopflerfish.org
BSD 3-Clause "New" or "Revised" License
33 stars 11 forks source link

Improve framework log message when unable to resolve #62

Closed d3bjorn closed 2 years ago

d3bjorn commented 2 years ago

Improve framework log message when unable to resolve https://github.com/knopflerfish/knopflerfish.org/issues/42

d3bjorn commented 2 years ago

As far as I can see, this is the only place where we say "unable to resolve" in knopflerfish.org.

chlarsson commented 2 years ago

OK, but is the underlying problem(s) propagated and logged correctly with this change?

d3bjorn commented 2 years ago

I think so. It looks like BundleImpl calls resolvePackages on BundleGeneration, which calls resolvePackages on BundlePackages, which calls the Resolver, and if there is a failReason returned from Resolver, the "unable to resolve" BundleException is thrown with the failReason in its message.

When I run the tests, the framework_test bundle causes this to be logged a few times, which seems to be expected by those tests.

d3bjorn commented 2 years ago

Maybe we want to include the bundle name in similar BundleException messages? For example, I found it very useful to include it for "start failed" when investigating test bundles failing to start.

chlarsson commented 2 years ago

Sound like a good idea.

Just a quick note - can we be sure the bundle name / symbolic name is always present if a bundle fails to a) resolve or b) fails to start? Or can it be null in certain cases

d3bjorn commented 2 years ago

It looks like the name can be null, but I think that's a rare case and getting "null" would be ok in those cases. It looks like, in theory, current BundleGeneration could be missing after using the system bundle's BundleImpl constructor, but if that happens BundleImpl would crash very hard before trying to log anything, so I don't think it can actually happen.