Logging bundle resolution errors

[thomas.diesler]

The proposed resolution to JBOSGI-439 is

            try {
                ResolverPlugin resolverPlugin = getFrameworkState().getResolverPlugin();
                resolverPlugin.resolve(resModule);
                return true;
            } catch (BundleException ex) {
                if (fireEvent == true) {
                    FrameworkEventsPlugin eventsPlugin = getFrameworkState().getFrameworkEventsPlugin();
                    eventsPlugin.fireFrameworkEvent(this, FrameworkEvent.ERROR, ex);
                } else {
                    // Make sure the reason for not resolving doesn't get lost, so log it.
                    log.errorf(ex, "Could not resolve bundle: %s", this);
                }
                return false;
            }

This however negates the purpose of the 'fireEvent' flag in terms of logging.

We have a number of places were we explicitly turn off logging/error events when resolution fails

[tdiesler@localhost jbosgi-framework]$ git grep "ensureResolved(false)"
core/src/main/java/org/jboss/osgi/framework/internal/HostBundleFallbackLoader.java:            if (bundle.ensureResolved(false) == false)
core/src/main/java/org/jboss/osgi/framework/internal/HostBundleRevision.java:        if (getBundleState().ensureResolved(false) == false)
core/src/main/java/org/jboss/osgi/framework/internal/HostBundleRevision.java:        if (getBundleState().ensureResolved(false)) {
core/src/main/java/org/jboss/osgi/framework/internal/HostBundleState.java:            if (ensureResolved(false) == false)

The most obvious one is for dynamic imports when we iterate over installed bundles and try to resolve them silently in order to check whether the import can be sattisfied.

Bundle resolution is triggered by

• Bundle start
• Bundle class load
• Bundle resource load
• Dynamic and optional imports

The rational with the code was that the caller decides whether an event is fired. In case of an error event the cause would be logged.

[thomas.diesler]

The propper fix might be to enable the error event in

HostBundleState.startInternal

            // #4 If this bundle's state is not RESOLVED, an attempt is made to resolve this bundle.

            // If the Framework cannot resolve this bundle, a BundleException is thrown.

            if (ensureResolved(false) == false)

                throw new BundleException("Cannot resolve bundle: " + this);

Not sure what the TCK expects in terms of events

[bosschaert]

Hmmm maybe the case I was looking at the ensureResolved(false) should have been a ensureResolved(true) instead. It's called from HostBundle.startInternal() (since the refactoring this code has moved elsewhere now). Maybe the startInternal() should call ensureResolved(true) instead? Any thoughts here?

The problem I was facing here is that with any deployment (e.g. through the deployments folder) that has unresolved dependencies it was impossible to find out why (unless you fire uyp a debugger). In all of these cases ensureResolved was always called with 'false'.

[thomas.diesler]

Done

https://github.com/jbosgi/jbosgi-framework/commit/eac5f317da9e