[
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:
try
{
return m_contentLoader.getSearchPolicy().findClass(name);
}
catch (ClassNotFoundException ex)
{
m_logger.log(
Logger.LOG_WARNING,
ex.getMessage(),
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.