| Listeners, Extension Points, Plugin/Bundle stop and NoClassDefFoundError [message #280301] |
Tue, 01 February 2005 14:23  |
Eclipse User |
|
|
|
Hi All,
I am just wondering how the following can/should be supported.
We have a set of plugins that work together.
One of the plugins sets up a framework that the others plug into and
does know about other plugins (i.e. no requires dependency on the
others). It declares extension points to allow other plugins to extend
it, as well as API that allow other plugins to register listeners to it.
During the stop processing, the framework needs to be able to call the
other plugins to let them clean up after themselves. This is where the
problem lies. We ended up with a bunch of NoClassDefFoundError. It looks
almost as if the plugins extending the framework has already been
stopped, and the ClassLoader chain has been disabled.
This seems like a pretty reasonable scenario. What am I missing? Has
anyone else seen this? What are we doing wrong? Any suggestions on what
we can try?
Thanks in advance for any suggestions and thoughts.
Mike Kwong
|
|
|
|
|
| Re: Listeners, Extension Points, Plugin/Bundle stop and NoClassDefFoundError [message #280316 is a reply to message #280310] |
Tue, 01 February 2005 16:46  |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
Michael,
A good practice for plug-ins that provide extension points that support
executable extensions is, before calling the extensions, to make sure
the platform is not shutting down:
if (bundleContext.getBundle(0).getState() == Bundle.STOPPING)
// we are shutting down, avoid calling listeners
return;
// here it is safe to call other plug-ins
You don't have to check before every call you make. If you have a loop
where you call all listeners, for instance, checking once before looping
through the listeners list should be good enough.
But again, if the plug-ins extending the framework plug-in
programmatically register themselves as listeners, I would expect them
to explicitly unregister themselves when shutting down. In this case,
the checking suggested above would be just a safety net because, in the
shutdown case, no listeners would have been left behind anyway.
Rafael
Michael Y Kwong wrote:
> Rafael Chaves wrote:
>
>> I would have expected that the plug-ins using the framework would do
>> any clean-up themselves when they had been stopped (what happens
>> before the framework plug-in is stopped).
>>
>> Rafael
>>
>
> Hi Rafael,
>
> What the framework has is a set of notification events that it sends to
> the plugins extending it to let them know about changes and events that
> are happening (e.g. connecting and disconnecting to a remote
> repository). The events are generated as part of the shutdown of the
> workbench. So we reuse the same code while the workbench is up and when
> the workbench is shutting down to do processing such as persist the
> model, clean up, etc.
>
> It may be possible to write extra clean up code in each of the plugin
> stop method to handle all that, but it's not clear we can reconstruct
> the complete context (normally supplied as part of the notification
> events) from there.
>
> Am I missing something? This does not seem that far-fetched a scenario
> for an extensible framework. Is there a safe point for a plugin to call
> back registered classes to do whatever processing one needs to do safely?
|
|
|
| Re: Listeners, Extension Points, Plugin/Bundle stop and NoClassDefFoundError [message #280390 is a reply to message #280316] |
Wed, 02 February 2005 17:33 |
| Eclipse User |
|
|
|
Originally posted by: cagatayk.stop.acm.org
Rafael Chaves wrote:
> Michael,
> A good practice for plug-ins that provide extension points that support
> executable extensions is, before calling the extensions, to make sure
> the platform is not shutting down:
> if (bundleContext.getBundle(0).getState() == Bundle.STOPPING)
> // we are shutting down, avoid calling listeners
> return;
> // here it is safe to call other plug-ins
Would Platform.isRunning() also work? The documentation is not clear
whether this returns false during shutdown.
(snip)
> Rafael
> Michael Y Kwong wrote:
>> Rafael Chaves wrote:
>>
>>> I would have expected that the plug-ins using the framework would do
>>> any clean-up themselves when they had been stopped (what happens
>>> before the framework plug-in is stopped).
>>>
>>> Rafael
>>>
>>
>> Hi Rafael,
>>
>> What the framework has is a set of notification events that it sends to
>> the plugins extending it to let them know about changes and events that
>> are happening (e.g. connecting and disconnecting to a remote
>> repository). The events are generated as part of the shutdown of the
>> workbench. So we reuse the same code while the workbench is up and when
>> the workbench is shutting down to do processing such as persist the
>> model, clean up, etc.
>>
>> It may be possible to write extra clean up code in each of the plugin
>> stop method to handle all that, but it's not clear we can reconstruct
>> the complete context (normally supplied as part of the notification
>> events) from there.
>>
>> Am I missing something? This does not seem that far-fetched a scenario
>> for an extensible framework. Is there a safe point for a plugin to call
>> back registered classes to do whatever processing one needs to do safely?
|
|
|
|
| Re: Listeners, Extension Points, Plugin/Bundle stop and NoClassDefFoundError [message #280396 is a reply to message #280394] |
Wed, 02 February 2005 18:43 |
| Eclipse User |
|
|
|
Originally posted by: cagatayk.stop.acm.org
Rafael Chaves wrote:
> Cagatay Kavukcuoglu wrote:
>> Would Platform.isRunning() also work? The documentation is not clear
>> whether this returns false during shutdown.
> Nope. The platform in this context means the platform runtime plug-in,
> and it will only change to "not running" when the runtime plug-in shuts
> down. Since the runtime plug-in is required by every Eclipse plug-in
> (otherwise they would just be regular OSGi bundles), it is always the
> last one to be stopped.
> Rafael
Ah. That caused a bit of questioning (why would the system bundle be
STOPPING first if core runtime is still running?) until I found this in
org.eclipse.osgi.framework.internal.core.Framework:
public synchronized void shutdown() {
/* Return if framework already stopped */
if (!active) {
return;
}
/*
* set the state of the System Bundle to STOPPING.
* this must be done first according to section 4.19.2 from the OSGi R3
spec.
*/
systemBundle.state = AbstractBundle.STOPPING;
|
|
|
Powered by
FUDForum. Page generated in 0.05884 seconds
Home