Jetty java files cannot be deleted java files occupy delete invalid runtime locking static Resources solution, jettydelete

Jetty java files cannot be deleted java files occupy delete invalid runtime locking static Resources solution, jettydelete
A few days ago, jetty found that java could not delete files. After file operations, it had been occupied by jvm, but the tomcat problem disappeared. Today I think again, I tried to solve the problem on the Internet. After my experiment, modifying the configuration file directly sometimes cannot take effect. The specific reason is unclear. We recommend that you directly modify the red part in the following section of the web. xml file.

The file is locked because jetty maps these files in the memory by default when using windows, and windows locks the memory-mapped files. The solution is to modify the jetty configuration so that it can set the useFileMappedBuffer flag to false when starting the server.

You can use either of the following methods to modify the useFileMappdBuffer flag in the webdefault. xml file. The webdefault. xml file is the configuration file for jetty to start the service, which is loaded prior to the WEB-INF/web. xml file in the project. The jetty package contains this file by default, which can be extracted, saved in the project root directory, and modified by useFileMappedBuffer node.

12	<param-name>useFileMappedBuffer</param-name><param-value>false</param-value>

Add a reference to this file in build. gradle.

123	[jettyRun, jettyRunWar,jettyStop]*.with { webDefaultXml = file("${rootDir}/webdefault.xml")}

The second method is to modifyWEB-INF/web.xmlFile.

123456789

<servlet> <!-- Override init parameter to avoid nasty --> <!-- file locking issue on windows. --> <servlet-name>default</servlet-name> <init-param> <param-name>useFileMappedBuffer</param-name> <param-value>false</param-value> </init-param></servlet>

The delete () method of java file class cannot delete objects.

Through fileTxt [j], you can see that you are deleting cyclically. You have determined whether the file exists, but not whether it is a folder or whether there are files in the folder.

Because when there are files in the folder, executing delete () fails.
In addition, the file you are deleting may be opened by another person or program, and the deletion will not succeed at this time.

Refer to the Java. io. File class of java API:
Delete
Public boolean delete ()

Delete the file or directory represented by this abstract path name. If the path name represents a directory, the directory must be empty before deletion.

Shortly after learning java, I just wrote a method to delete files or folders. The first form is private void deleteFile (File file) {if

You read less of the brackets.
The two are similar, but the first form is not standardized. if the parameter of the function is a file, it is deleted in the first if. The next one deletes a deleted file. If it is a folder, delete the folder. To normalize
If (file. isFile ()){
File. delete ();
} Else
Remove, and add only the isDirectory judgment.
That is, the program is changed:
Private void deleteFile (File file ){
If (file. isDirectory () {// Delete all files in the directory, if it's the case
File files [] = file. listFiles ();
For (int I = 0; I <files. length; I ++ ){
This. deleteFile (files [I]);
}
}
Else if (! File. exists () {// File not exist
System. out. println ("the deleted file does not exist! "+ '\ N ');
Return;
}
File. delete (); // Delete the file or the directory
}
In the second form, if it is a file, delete the file; if it is a folder, delete the content in the folder, and then delete the folder itself.
------------------------------------------
To sum up, the first form is deleted repeatedly when the file is of the file type, and the second form does not. It is not the difference outside of. :)