Done: https://issues.apache.org/jira/browse/FELIX-674
On Thu, Aug 7, 2008 at 10:55 PM, Karl Pauls <[EMAIL PROTECTED]> wrote: > > > Am 07.08.2008 um 11:29 schrieb "Don Brown" <[EMAIL PROTECTED]>: > >> Oh, when did Felix 1.1 come out or are you using even minor versions >> for stable releases? > > Yes that is what we do. > >> 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? > > probably best to create jira issue with a describtion of what you need. > > regards, > > Karl > >> >> 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] >> > > --------------------------------------------------------------------- > 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]
