关于Java中Web应用程序的“org.eclipse.wst.server.core”文件夹的一般问题很少

Question

I have a few questions regarding the org.eclipse.wst.server.core folder in .metadata\\.plugins folder in a eclipse work space. I know that while running an application in local host, this is the folder where we have to replace files for front end, like JSP , JS files, CSS files, HTML files, Images etc.

There will be some tmp folders into which I have to replace the files into respective locations. This folder will be having another folder with structure of a WAR file which I'll take from my work space and sometimes there will be multiple tmp folders like tmp0 , tmp1 , tmp2 etc (most of them having all required files). When there are multiple folders it is really confusing to decide that into which folder I need to replace the file(s).

Then I'll have to stop the server, kill all the java running in background (manually) and have to clear all the tmp folders (because if the java is not killed properly the jar files inside tmp 's cannot be deleted saying its currently being used). I guess one among these tmp folders are used by the server to run the application.

After cleaning all the tmp folders if I start the server again, the first file created in that folder ( org.eclipse.wst.server.core ) will be one servers.xml , then one tmp0 will be created may be tmp1 . When entire project is published only one tmp folder will be there, if I publish multiple times, another tmp folder will be created, may be 2nd time, 3rd time or nth time.

So my questions are

1. Is there a general name for org.eclipse.wst.server.core folder?

2. Why multiple tmp folders are created when publised multiple times? Can we restrict it into a single tmp folder?

3. After the project is published, is there a possibility that server will use multiple tmp folders for different request. Like for first request I uses tmp0 and when I refresh the page it uses tmp1 folder?

Edited regarding the 3rd question

I opened all the xml files in the folder given in the above image, and in tmp-data.xml , I found this content

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<temp-directories>
  <temp-directory age="0" key="GlassFish v2.1 Java EE 5 at localhost" path="tmp0"/>
</temp-directories>

Where path attribute is given value as tmp0 . So I'm guessing that will be the answer to my third question. I'm guessing this file will be created when there are multiple tmp folders, because after deleting all tmp folders and files in the folder and after publishing the work space the tmp-data.xml file was not present.

Edited regarding the WTP

I don't have much details about WTP, but when I clicked Help and selected About Eclipse in my eclipse I got this window

Answer 1

1. Not that I know of. It is created by WTP (Web Tools Platform) using WST (Web Standard Tools). If you find, let me know too.

2. That depends upon different checks that WTP and WST do before publishing the artifacts. It does not happen all the time, but it does a lot more than expected, because of file locks that stop eclipse from publishing a fresh copy of the application. And hence, the code must be trying to create new tmp folder just as a workaround. The metadata (publish.xml) is then updated, and everything works as normal, which I feel is much better since the developer does not have to know a lot of stuff about these failures. We can change this setting in the server properties in your eclipse. Note that different plugins have different ways of doing this, my STS has default deploy path set to wtpwebapps.

3. This must be available in your publish xml file. And it also depends upon the version of WTP / WST you are using. It is hard to see where the folder generation is happening (at least for me at this time), but you can look at PublishUtils.java and PublishDelegate.java in WTP. Github here .

4. No certainly not, after a project is published the whole server points to the location at which the artifacts reside. Though the context refresh might fail because of overlapping threads or wait time, it is not possible for two different instances to be deployed into the same server with the same application/context name.

Read this and this