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. My question is what is the best way to get a better hold of this exception? One thought was to implement a logger that checks a threadlocal variable that contains a shouldThrowClassNotFoundExceptions() to see if it should treat the exception as more serious. Obviously, due to performance and memory leak concerns, I'd like to avoid this, but I don't see any other way right now. Thanks, Don --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
