Oh, when did Felix 1.1 come out or are you using even minor versions for stable releases? The plugin framework core will have its final release in the next few days, but even if I went with the threadlocal option, it wouldn't make it for 2.0 (the aforementioned final release), but options for 2.1 are open. Having a new Felix release by the end of the month that has improved error reporting would be wonderful. Is there anything I can do to help, or should I bring that discussion over to the dev list?
Don On Thu, Aug 7, 2008 at 7:37 PM, Karl Pauls <[EMAIL PROTECTED]> wrote: > We are planning to have Felix 1.2 out by the end of the month. In case that > would be soon enough for you is there something we can do to make your live > easier? > > regards, > > Karl > > Am 07.08.2008 um 11:07 schrieb "Don Brown" <[EMAIL PROTECTED]>: > >> 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] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
