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]
