Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 348613 - Could not delete metadata file when removing utility jar application from server
Summary: Could not delete metadata file when removing utility jar application from server
Status: RESOLVED NOT_ECLIPSE
Alias: None
Product: WTP ServerTools
Classification: WebTools
Component: wst.server (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Larry Isaacs CLA
QA Contact: Angel Vera CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-07 13:32 EDT by Steven Hung CLA
Modified: 2011-06-17 10:12 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Hung CLA 2011-06-07 13:32:41 EDT
Build Identifier: 3.7.0 I20110526-1708

Server: Tomcat 6.0

A dialog with title "Problem Occurred" is displayed with text:
Could not delete D:\WTPIndigo\eclipse\workspace\smoketest\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\Testing\WEB-INF\lib\Utility.jar. May be locked by another process.

The server log also displays:
Jun 7, 2011 1:29:59 PM org.apache.catalina.session.StandardManager doUnload
SEVERE: IOException while saving persisted sessions: java.io.FileNotFoundException: D:\WTPIndigo\eclipse\workspace\smoketest\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\Testing\SESSIONS.ser (The system cannot find the path specified)
java.io.FileNotFoundException: D:\WTPIndigo\eclipse\workspace\smoketest\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\Testing\SESSIONS.ser (The system cannot find the path specified)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:489)
	at org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
	at org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
	at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4611)
	at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3222)
	at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:403)
	at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1309)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
	at java.lang.Thread.run(Unknown Source)
Jun 7, 2011 1:29:59 PM org.apache.catalina.session.StandardManager stop
SEVERE: Exception unloading sessions to persistent storage
java.io.FileNotFoundException: D:\WTPIndigo\eclipse\workspace\smoketest\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\Testing\SESSIONS.ser (The system cannot find the path specified)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:489)
	at org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
	at org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
	at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4611)
	at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3222)
	at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:403)
	at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1309)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
	at java.lang.Thread.run(Unknown Source)

Reproducible: Always

Steps to Reproduce:
1. Create a dynamic web proj
2. Create a java project (this is the utility project)
3. Add the java project to the web proj
4. Make reference to the java project in the dynamic web proj via deployment assembly
5. Publish app to the server
6. Run the servlet
7. Remove the app, the error will be displayed
Comment 1 Steven Hung CLA 2011-06-16 14:11:22 EDT
This also affects Eclipse 3.6.2 M20110210-1200
Comment 2 Elson Yuen CLA 2011-06-16 14:23:34 EDT
It looks like the problem may be caused by the SESSIONS.ser file gets deleted prematurely before all required operation has been completed when removing an application from the tomcat server.
Comment 3 Larry Isaacs CLA 2011-06-17 10:12:13 EDT
Sorry for not addressing this sooner.  Jar locking is a feature of Windows.  However, even running on Linux, adding and removing of projects from a running Tomcat is not really supported in WTP.  This is addressed, in the Tomcat FAQ here:

http://wiki.eclipse.org/WTP_Tomcat_FAQ#Can_I_add_or_remove_a_project_from_a_server.2C_or_publish_changes_for_a_project_already_on_a_server.2C_while_that_server_is_running.3F

Due to the Windows jar locking and the fact that the "antiJarLocking" offered by Tomcat interferes with publishing, I'm marking this as NOT_ECLIPSE.

There is still the issue that the Tomcat support in WTP doesn't currently have a good way request individual webapp's be started and stopped.  This is the issue with the SESSIONS.ser file.  JMX might be a possibility, but the number of cycles I think that would take would be impractical.  This is due to the limited success possible because of the jar locking on Windows and the challenge of getting something to work across multiple versions of Tomcat.