3 Replies Latest reply: May 3, 2011 4:06 AM by Thomas Diesler RSS

Logging bundle resolution errors

Thomas Diesler Master

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.

  • 1. Logging bundle resolution errors
    Thomas Diesler Master

    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

  • 2. Logging bundle resolution errors
    David Bosschaert Expert

    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'.