You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Don Brown <do...@gmail.com> on 2008/08/07 11:07:21 UTC
Better error reporting for loaded classes
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Better error reporting for loaded classes
Posted by Don Brown <do...@gmail.com>.
Done: https://issues.apache.org/jira/browse/FELIX-674
On Thu, Aug 7, 2008 at 10:55 PM, Karl Pauls <ka...@gmail.com> wrote:
>
>
> Am 07.08.2008 um 11:29 schrieb "Don Brown" <do...@gmail.com>:
>
>> 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 <ka...@gmail.com> 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" <do...@gmail.com>:
>>>
>>>> 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Better error reporting for loaded classes
Posted by Karl Pauls <ka...@gmail.com>.
Am 07.08.2008 um 11:29 schrieb "Don Brown" <do...@gmail.com>:
> 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 <ka...@gmail.com>
> 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" <do...@gmail.com>:
>>
>>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Better error reporting for loaded classes
Posted by Don Brown <do...@gmail.com>.
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 <ka...@gmail.com> 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" <do...@gmail.com>:
>
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Better error reporting for loaded classes
Posted by Karl Pauls <ka...@gmail.com>.
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" <do...@gmail.com>:
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org