Bugzilla – Full Text Bug Listing
| Summary: | NullPointerException in WTP Tomcat when project is recompiled | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Howard Lee <howardtzelee> | ||||
| Component: | jst.server | Assignee: | Larry Isaacs <larryisaacs> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Angel Vera <arvera> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | fgiust, kenneth.chenis, mariano.fernandez, patric, thatnitind | ||||
| Version: | 3.2 | Flags: | arvera:
review+
|
||||
| Target Milestone: | 3.2.2 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| See Also: | https://git.eclipse.org/r/108977 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Howard Lee
At first I wasn't so certain this belongs to us but I then was able to find org.eclipse.jst.server.tomcat.runtime.xx.loader.jar inside of out org.eclipse.jst.server.tomcat.core plugin. I am not sure how they get build but Larry over to you. This is likely part of Tomcat's "leak prevention" code, which may be tricky to program around. I'll have to investigate to see what my options are. Regardless, it would be helpful to know which version of Web Tools and Tomcat you are using. Created attachment 173251 [details]
Eclipse configuration information
(In reply to comment #2) > This is likely part of Tomcat's "leak prevention" code, which may be tricky to > program around. I'll have to investigate to see what my options are. > Regardless, it would be helpful to know which version of Web Tools and Tomcat > you are using. I'm using Helios Eclipse J2EE, which appears to use WTP 3.2 (see uploaded configuration for additional details). Using Tomcat 6.0.26 (JDK 1.6 32-bit Windows). I did not have this problem with Eclipse 3.5.2. I too get this error, and it is 100% reproducable, however my stack trace is different, and I only get this when publishing if I set "Server modules without publishing" - if enabled I get this error always, if disabled, no error: !ENTRY org.eclipse.jst.server.tomcat.core 4 0 2010-08-02 17:34:06.425 !MESSAGE Could not publish server configuration: null. !STACK 0 java.lang.NullPointerException at org.eclipse.wst.common.componentcore.internal.resources.VirtualContainer.createVirtualResource(VirtualContainer.java:355) at org.eclipse.wst.common.componentcore.internal.resources.VirtualContainer.getResources(VirtualContainer.java:338) at org.eclipse.jst.server.tomcat.core.internal.TomcatPublishModuleVisitor.endVisitWebComponent(TomcatPublishModuleVisitor.java:293) at org.eclipse.jst.server.tomcat.core.internal.wst.ModuleTraverser.traverseWebComponent(ModuleTraverser.java:220) at org.eclipse.jst.server.tomcat.core.internal.wst.ModuleTraverser.traverse(ModuleTraverser.java:117) at org.eclipse.jst.server.tomcat.core.internal.TomcatVersionHelper.updateContextsToServeDirectly(TomcatVersionHelper.java:854) at org.eclipse.jst.server.tomcat.core.internal.Tomcat60Configuration.updateContextsToServeDirectly(Tomcat60Configuration.java:686) at org.eclipse.jst.server.tomcat.core.internal.TomcatServerBehaviour.publishFinish(TomcatServerBehaviour.java:454) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:954) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:775) at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:2888) at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:337) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Eclipse: Helios Release 20100617-1415 Tomcat: 6.0.28 Java: JDK 1.6.0_21 X64 Startup Command Line: start eclipse.exe -data ..\..\Data\WorkSpace -vm ..\jdk\bin\javaw -vmargs -Xmx1024M -Xms512M -XX:MaxPermSize=256M OS: Windows 7 Enterprise Ken, This bug is referring to an NPE which is occurring in the running Tomcat where yours is occurring within Eclipse. Please open a separate bug for your problem. It wouldn't hurt to attach the ".settings/org.eclipse.wst.common.component" file from the project so I can see if there is anything unusual that would lead to your NPE. Larry I am getting exactly the same NPE, and it looks like it's due to WtpDirContext trying to accessing a non-existing WEB-INF/classes dir.
For some reason here the WEB-INF/classes seems to be added to the classpath checked by the tomcat loader, although it shoudn't.
In my org.eclipse.wst.common.component I have two entries which refer to WEB-INF/classes:
<wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/java"/>
<wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/resources"/>
Anyway, when "serve modules without publishing" is enabled the deploy path specified there should not be used as a real classpath entry.
HTH
I upgraded WTP to 3.2.1 and this problem has vanished for me. So I'm not going to open a new bug as Larry suggested at this would not be reproduced with the latest version. Thanks for the help. The problem is that in recent versions of Tomcat 6.0.x, reloading of a context is calling the release() method on the WtpDirContext, which nulls its instance fields, then later tries to use the WtpDirContext to load a class as part of the "leak prevention" handling. As written, WtpDirContext isn't written for this use case since it assumed that once release() was called, it wouldn't be used. It appears the "quirk" of calling release() and then trying to use the WtpDirContext has been fixed in Tomcat 7.0.x, as I don't see the NPE there. The solution is to add enough null checking to respond appropriately if WtpDirContext is used after release() has been called. Angel, I have new source zips (i.e. org.eclipse.jst.server.tomcat.runtime.NN.loader-src.zip files) and custom jars (i.e. org.eclipse.jst.server.tomcat.runtime.NN.loader.jar files) ready to commit to address this. I would like to include this in WTP 3.2.2 as it does interfere with Tomcat "leak prevention" code. I have made the same updates for all versions of Tomcat just for consistency. Since this is custom Tomcat code, I don't have diffs to show what changed. However, the changes were all simple null checks. I can attach one of the source zips if you like. If you approve, I'll commit to WTP 3.2.2 in addition to WTP 3.3. Thanks. Fabrizio, The info you cite isn't the cause of the NPE. Once I commit the updated jar, you should be able to download one from CVS and replace the one Tomcat is using. That should get rid of the NPE. It there is still an issue related to a non-existent "WEB-INF/classes" on the classpath, ask on the WTP newsgroup or open a separate bug so we can look into it. Thanks. General FYI: Ken's problem was Bug 317834 which was fixed in WTP 3.2.1. More null checks are always good, so I am okay with that. What is not clear is what will happend in the case that is null. What is the correct behaviour? will this function simply failed (ie. nothing will happen) or will there be a gracious error? I would say the behavior of these Tomcat "naming context" classes, like our WtpDirContext, is technically undefined after the release() method is called. However, it's fairly clear what would be more graceful than throwing an NPE in the various methods, typically returning null or throwing a NamingException. With these changes, anything that goes wrong will be Tomcat's fault and not the fault of our custom class because it threw and unexpected NPE. Since it's a Tomcat bug that it is calling release() and then using the WtpDirContext, it's likely that this bug's NPE is the only one that would occur. With these changes, I believe Tomcat's "leak prevention" code would be able to continue normally. I addressed all possible NPE's just to be on the safe side. Thanks for the extra explanation. I approve Changes released to WTP 3.2.2 and HEAD. The updated Tomcat 6.0.x version of the custom jar can be downloaded using: http://dev.eclipse.org/viewcvs/index.cgi/servertools/plugins/org.eclipse.jst.server.tomcat.core/org.eclipse.jst.server.tomcat.runtime.60.loader.jar?revision=1.3.2.1&root=WebTools_Project Overwrite the one that was copied to the Tomcat 6.0.x installation. *** Bug 325671 has been marked as a duplicate of this bug. *** New Gerrit change created: https://git.eclipse.org/r/108977 |