felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-674) Better error reporting when loading bundle classes
Date Mon, 18 Aug 2008 01:58:45 GMT

    [ https://issues.apache.org/jira/browse/FELIX-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623243#action_12623243

Don Brown commented on FELIX-674:

The fun starts at BundleImpl line 358:
return m_felix.loadBundleClass(this, name);

Felix.loadBundleClass() makes sure the bundle is resolved then this at line 1525:
Class clazz = bundle.getInfo().getCurrentModule().getClass(name);
if (clazz == null)
    throw new ClassNotFoundException(name);
return clazz;

Notice the exception isn't linked to the underlying exception because in ModuleImpl line 177:

            return m_contentLoader.getSearchPolicy().findClass(name);
        catch (ClassNotFoundException ex)
        return null;

it decides to swallow the exception, log a warning, and return null.  Ideally, we would let
the exception bubble up so the exception would chain properly, but that might have other implications.

> Better error reporting when loading bundle classes
> --------------------------------------------------
>                 Key: FELIX-674
>                 URL: https://issues.apache.org/jira/browse/FELIX-674
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: felix-1.0.4
>            Reporter: Don Brown
>            Assignee: Karl Pauls
>             Fix For: felix-1.2.0
> We (Atlassian) are in the middle of a rollout of our new plugin
> framework that has Felix at its core.  The plugin system operates on
> top of existing Java webapps as an embedded container, with plugins
> exposing XML configuration defining what plugin extension points they
> implement.  When the plugin is started, the web application needs to
> resolve that class name to a class instance, which is currently
> implemented using Bundle.loadClass().
> However, the Bundle.loadClass() method is swallowing the root cause of
> any exception causing the class to not be resolved, so if it is trying
> to load FooPlugin, which fails due to a missing class dependency of
> FooPlugin, Bundle.loadClass() throws a ClassNotFoundException that
> says FooPlugin wasn't found, which is misleading.  I traced it down
> (version 1.0.4) to ModuleImpl.getClass(), which swallows any
> exceptions by only logging them as a warning.  Unfortunately, the warn
> messages are given a lower priority by the host application due to a
> number of warnings that happen as a natural part of the loading
> sequence.
> This ticket asks for better error reporting ideally through proper chained exceptions.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message