Community
Participate
Working Groups
java.lang.NullPointerException at org.eclipse.jst.server.tomcat.core.tests.Tomcat50ServerTestCase.verifyPublishedModule(Tomcat50ServerTestCase.java:44) at org.eclipse.jst.server.tomcat.core.tests.AbstractTomcatServerTestCase.verifyLegacyAddPublish(AbstractTomcatServerTestCase.java:289) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:416) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:249) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
My analysis is that this is a spurious failure caused by how the test is written. This particular test, and probably others, execute a sequence of steps as fast as code will allow, resulting in the potential for race conditions. For this particular test, the server configuration is being modified, a module added, and then the server published. The configuration change appears to have caused a cached configuration to get discarded out from under the publish operation leading to the NPE. I'm still digging into the exact scenario that results in this NPE, but I suspect one or more of these steps should probably be performed in a Job so workspace notifications can be processed before moving on to the next step. Also, I see how I can make a small change so this NPE would be less likely regardless of any testing changes, so I'll see about including that in WTP 3.2.3 and 3.3. In any event, I don't believe this failure represents any new issue in WTP and I would not expect it happen in the next build.
Created attachment 185967 [details] Patch to TomcatServer to allow asynchronous calls to it's configurationChanged() method These are the changes I plan to commit to address the NPE. It uses version counting to trigger reloading of Tomcat's configuration instead of nulling the configuration. It avoids the NPE which can occur if configurationChanged() is called while the configuration is being loaded.
Angel, Please review for inclusion in WTP 3.2.3. To be included are version bumps for tomcat.core, server_adapters.ext.feature, and server_adapters.ext.sdk.feature. Thanks.
Look good
Fix released to HEAD and 3.2 maintenance and appear in current WTP 3.3 and 3.2.3 builds.
New Gerrit change created: https://git.eclipse.org/r/109016
