Re: [equinox-dev] Exceptions accessing preferences during shutdown

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Yes, please look at that as part of
adding the new automation stuff.  

We should also consider having activation
be a one time function.  That is, once a particular plugin has been
activated (its classloader used) then it should not be reactivated.  If
it is updated (classloader tossed) then it can be activated again.  I
suspect that the current code actually works and as you observe, it is
the explicit start() call in createExectableExtension() that is the problem.

That call may be bogus (or be there)
for another reason.  If the class provided in the extension comes
from some other plugin, the plugin providing the extension will not be
activated by classloading.  So the start() call during creation will
force the activation.  This seems somewhat heavy handed.  Try
pushing forward on NOT activating during executable extension creation.

Jeff

Rafael Chaves/Ottawa/IBM@IBMCA
Sent by: equinox-dev-admin@xxxxxxxxxxx

03/16/2004 10:48 AM

Please respond to
equinox-dev

To	equinox-dev@xxxxxxxxxxx
cc
Subject	Re: [equinox-dev] Exceptions accessing preferences during shutdown

Actually, we don't need to force bundle activation during creation of executable
extensions. I think that code is from before we had auto-activation provided
by the class loader. 


----- Forwarded by Rafael Chaves/Ottawa/IBM on 16/03/2004 10:47 AM -----

Rafael Chaves/Ottawa/IBM

16/03/2004 10:44 AM

To	equinox-dev@xxxxxxxxxxx
cc
Subject	Re: [equinox-dev] Exceptions accessing preferences during shutdownLink

I have been seeing this as well. Generally speaking, a plugin being shutdown
should not cause others to be started, because it defeats the purpose of
shutting down plugins. 

In this case, it seems the resources plugin is causing itself to be re-activated.
ConfigurationElement#createExecutableExtension will try to start the bundle
that provided the executable extension class unless its state is ACTIVE
| STARTING. Maybe we should extend that test to not try to start the bundle
when it is STOPPING too. 

It seems the resources plugin is creating

John Arthorne/Ottawa/IBM@IBMCA
Sent by: equinox-dev-admin@xxxxxxxxxxx

15/03/2004 07:03 PM

Please respond to
equinox-dev

To	equinox-dev@xxxxxxxxxxx
cc
Subject	[equinox-dev] Exceptions accessing preferences during shutdown

I'm seeing these exceptions in my runtime workbench log.  It looks
like you can't create executable extensions during a bundle shutdown? If
so, is this a reasonable limitation for the runtime to impose?


org.osgi.framework.BundleException: Bundle state change in progress
at java.lang.Throwable.<init>(Throwable.java)
at java.lang.Throwable.<init>(Throwable.java)
at org.osgi.framework.BundleException.<init>(BundleException.java:68)
at org.eclipse.osgi.framework.internal.core.Bundle.beginStateChange(Bundle.java:1228)
at org.eclipse.osgi.framework.internal.core.Bundle.start(Bundle.java:333)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:133)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:125)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:114)
at org.eclipse.core.internal.preferences.PreferencesService.createNode(PreferencesService.java:75)
at org.eclipse.core.internal.preferences.RootPreferences.node(RootPreferences.java:105)
at org.eclipse.core.internal.preferences.EclipsePreferences.node(EclipsePreferences.java:533)
at org.eclipse.core.resources.ResourcesPlugin.shutdown(ResourcesPlugin.java:299)
at org.eclipse.core.internal.compatibility.PluginActivator.stop(PluginActivator.java:66)
at org.eclipse.osgi.framework.internal.core.BundleContext$2.run(BundleContext.java:1028)
at java.security.AccessController.doPrivileged(AccessController.java:189)
at org.eclipse.osgi.framework.internal.core.BundleContext.stop(BundleContext.java:1024)
at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:482)
at org.eclipse.osgi.framework.internal.core.Bundle.stop(Bundle.java:480)
at org.eclipse.core.internal.plugins.PluginStopper.run(PluginStopper.java:99)
at org.eclipse.core.internal.runtime.PlatformActivator.stopLegacyBundles(PlatformActivator.java:290)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:272)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:173)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41)
at java.lang.reflect.Method.invoke(Method.java:386)
at org.eclipse.core.launcher.Main.basicRun(Main.java:305)
at org.eclipse.core.launcher.Main.run(Main.java:745)
at org.eclipse.core.launcher.Main.main(Main.java:713)