Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325874

Summary: null resourceChangeListener causes org.eclipse.core.runtime.AssertionFailedException during shutdown
Product: [WebTools] WTP ServerTools Reporter: Troy Bishop <tjbishop>
Component: wst.serverAssignee: Elson Yuen <eyuen7>
Status: RESOLVED FIXED QA Contact: Angel Vera <arvera>
Severity: minor    
Priority: P3    
Version: 3.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
See Also: https://git.eclipse.org/r/109029
https://git.eclipse.org/r/109028
Whiteboard: plan_draft_324
Attachments:
Description Flags
possible patch
none
v1.0 none

Description Troy Bishop CLA 2010-09-21 12:15:12 EDT
Build Identifier: WTP 3.2.2

In a WTP adopter product I am experiencing the following error in the .log when the product is shutting down:

!ENTRY org.eclipse.wst.server.core 4 0 2010-09-21 12:03:01.498
!MESSAGE Error during shutdown
!STACK 0
org.eclipse.core.runtime.AssertionFailedException: null argument:
	at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
	at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
	at org.eclipse.core.internal.events.ResourceChangeListenerList.remove(ResourceChangeListenerList.java:146)
	at org.eclipse.core.internal.events.NotificationManager.removeListener(NotificationManager.java:305)
	at org.eclipse.core.internal.resources.Workspace.removeResourceChangeListener(Workspace.java:1934)
	at org.eclipse.wst.server.core.internal.ResourceManager.shutdownImpl(ResourceManager.java:367)
	at org.eclipse.wst.server.core.internal.ResourceManager.shutdown(ResourceManager.java:313)
	at org.eclipse.wst.server.core.internal.ServerPlugin.stop(ServerPlugin.java:360)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:843)
	at java.security.AccessController.doPrivileged(AccessController.java:251)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:836)
	at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:501)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:550)
	at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1097)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:597)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215)
	at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:266)
	at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:690)
	at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:588)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:415)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:198)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:600)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1383)

This is happening because ResourceManager#shutdown() is called directly during ServerPlugin#stop(BundleContext) and it doesn't check the state of the initialized flag.

I will attach a simple patch to prevent this problem from occurring.

Reproducible: Always
Comment 1 Troy Bishop CLA 2010-09-21 12:16:38 EDT
Created attachment 179328 [details]
possible patch
Comment 2 Troy Bishop CLA 2010-09-21 12:18:24 EDT
> This is happening because ResourceManager#shutdown() is called directly during
> ServerPlugin#stop(BundleContext) and it doesn't check the state of the
> initialized flag.
> 

To expand a bit, this is happening because the IResourceChangeListener instance (resourceChangeListener) and Preferences.IPropertyChangeListener (pcl) are both null... and removing a null listener causes the assertion failure shown above.  Checking the state of the initialized flag prevents this error from happening.
Comment 3 Elson Yuen CLA 2011-03-30 17:14:20 EDT
Created attachment 192227 [details]
v1.0

Updated patch for adding null check on top of previous patch.
Comment 4 Elson Yuen CLA 2011-03-30 17:15:28 EDT
Code released to 32M and 33M
Comment 5 Angel Vera CLA 2011-03-30 22:07:15 EDT
Code released to 32M
Comment 6 Eclipse Genie CLA 2017-10-11 16:35:59 EDT
New Gerrit change created: https://git.eclipse.org/r/109029
Comment 7 Eclipse Genie CLA 2017-10-11 16:36:01 EDT
New Gerrit change created: https://git.eclipse.org/r/109028