2020-06-09 11:57
@JFinal 这个我有在linux环境下tomcat8.5上测试过 内存占用会随着实例的reload 或者deploy不断增加但是运行过程并没有什么问题,只是使用tomcat的manager管理war包部署的时候发生,解决办法就是内存占用多了的时候重启一下tomcat的服务就好了。
2019-01-06 09:12
@JFinal
调试找到问题所在了。
ResourceManagerKit的buildResourceManager方法里面
ret.add(new FileResourceManager(new File(path)));
FileResourceManager使用的是默认构造
public FileResourceManager(final File base) {
this(base, 1024, true, false, null);
}
FileResourceManager构造第三个参数是文件路径是否大小写敏感,默认为true,这样就导致了在调用getFileResource的时候进入if (this.caseSensitive)分支后进行文件名大小写比对:
else if (isFileSameCase(file, normalizedFile)) {
log.tracef("Found path resource %s from path resource manager with base %s", path, base);
return new PathResource(file, this, path, eTagFunction.generate(file));
}
只有大小写完全一致才能调用PathResource读取资源
而我这里诡异的情况出现了:
private boolean isFileSameCase(final Path file, String normalizeFile) throws IOException {
String canonicalName = file.toRealPath().toString();
return canonicalName.equals(normalizeFile);
}
canonicalName在vscode中返回的盘符是大写,而normalizeFile盘符是小写(如D:/abc.txt与d:/abc.txt),导致两者不一致而返回false,在eclipse中两者盘符大小写是一样的,这样造成了vscode中无法读取到正确的资源。
其实根本原因是windows系统本身对文件路径大小写不敏感,这个情况在linux下因为大小写敏感就没有问题的,所以大佬能否在构建ResourceManager的时候对操作系统进行一下判断来决定new FileResourceManager()时的大小写敏感的参数,或者说提供一个setter让我们自己去设置也行。
2019-01-05 21:41
@JFinal
System.out.print(new File(".").getAbsolutelyPath());
这个测试了能输出项目的根目录的绝对路径
vscode启动调试到
ResourceManagerKit.class 中buildResourceManager方法里面的时候
0:"src/main/webapp" (id=81)
1:" webapp" (id=82)
2:" src/main/resources/webapp" (id=83)
3:" WebRoot" (id=84)
4:" WebContent" (id=85)
5个预留的地址在if里面都判断失败了 没有加到ret里面去
for (String path : resourcePathArray) {
path = path.trim();
if (new File(path).isDirectory()) {
ret.add(new FileResourceManager(new File(path)));
}
}
但是eclipse中调试就正常了 这就奇怪了。
2019-01-05 17:20
@JFinal System.out.println(JFinal.me().getServletContext().getRealPath("/")); 这个输出了null ,应该是和这个有关系了导致不能正确识别到web根目录。