2020-06-07 23:25
@124653847atqq.com 很多功能在 jfinal 中早已预埋，只是文档中没有而已
这些预埋功能，等待你哪天有需求的时候就可以用上了
2020-06-07 20:45
所以，这正是 Okv 出场的时候：
Okv fields = Okv.by("psncode", "人员编码");
...
renderJson(fields);
Okv 的缩写是： Ordered Key Value， 有序键值对
2020-06-06 22:28
@永字诀 只要证实下面这个就可以了：
JFinal.initPathKit() 中的 servletContext.getRealPath("/"); 获取到的值，取决于 undertow.resourcePath，使用的是第一个有效目录
其它的不是重点
2020-06-06 18:17
引入外部的 jar 包，出现这类问题，需要配置：
undertow.hotSwapClassPrefix=com.sl.jfinal.
也可以这么来配置：
UndertowServer.create(MyApp.class)
.addHotSwapClassPrefix("com.sl.jfinal.")
.start();
这里有文档：
https://jfinal.com/doc/1-5
原因是，jfinal undertow 默认只对 target/classes 以及 jfinal 做了 hotSwap ，从而 jfinal 与 target/classes 采用的是 HotSwapClassLoader
而你的 com.sl.jfinal. 下面的类 SwaggerValidatorHandler 继承了 jfinal 中的某些组件，但并未使用 HotSwapClassLoader 进行类加载，从而造成类型不对
这种类型不对，表面上看不出来，是因为它们被不同的 ClassLoader 所加载
2020-06-05 23:21
如果 A、B、C 方法都处在同一个线程之中，那么 DbKit.getConfig().getConnection() 得到的 Connection 对象将是共享的，所以无论 A、B、C 哪个方法中 commit() 都将影响其余两个方法
注意看 DbKit.getConfig() 这个方法的实现:
Connection conn = threadLocal.get();
if (conn != null)
return conn;
return showSql ? new SqlReporter(dataSource.getConnection()).getConnection() : dataSource.getConnection();
该方法是优先从 ThreadLocal 中获取 connection 对象，假定你的 A 方法最先调用该方法，后面的 B、C 如果与 A 处在同一个线程，那么获取到的对象与 A 中将是同一个。所以 A、B、C 的事务将融合为一个事务
解决办法自然就简单了：想办法获取独立的 Connection 对象，具体代码如下：
DbKit.getConfig().getDataSource().getConnection()
以上代码将获取到一个全新的 connection 对象，对该对象进行数据库操作，然后进行 commit() 将是它自己独享的
2020-06-05 22:37
@永字诀 这个就是关键了，这是因为 JFinal.initPathKit() 中的 servletContext.getRealPath("/"); 获取到的值，取决于 undertow.resourcePath
你配置不同的 undertow.resourcePath 值，然后在 JFinal.initPathKit() 中打个断点，就能看到值在不停的变化
当然，前提是你配置的 undertow.resourcePath 所指向的目录一定要是真实存在的
试一下以后再来回复一下
2020-06-05 22:00
在 PathKit.setWebRootPath(...) 中设置一个断点可以很容易看到这个执行过程
2020-06-05 22:00
@永字诀 UndertowKit.configJFinalPathKit(config) 只有在部署环境下才会被调用，因为非部署环境下， PathKit 中的 webRootPath 可以被正确获取
在 JFinal.initPathKit() 中有这样几行代码：
private void initPathKit() {
String path = servletContext.getRealPath("/");
PathKit.setWebRootPath(path);
}
非部署环境下 servletContext.getRealPath("/") 可以获取到正确的值。 部署环境下，这里获取的值应该是 null 值
2020-06-05 21:58
sql 的最外层如果带有 group by ，要对第三个参数传入一个 true，例如：
Db.template(...).paginate(1, 10, true);
如果还是报错，参考一下文档：
https://jfinal.com/doc/5-6
2020-06-05 21:51
异常信息已经很清楚：
java.lang.NoSuchMethodError
这种异常是 java 基础知识，多个同样功能的 jar 包冲突，或者 jar 包版本不对
使用下面方法检查：
1：打开 eclipse 中的项目
2：按快捷键: ctrl + shift + t， 会弹出一个 Open Type 对话框。如果弹不出来，在工具栏点按那个 "文档夹上面有两个不同颜色小球" 的按钮，也可弹出 Open Type 对话框
3：在对话输中输入：javax.servlet.ServletRequest
4：键盘方向键向下键，进入下方的列表
5：盯着列表下面的显示 jar 包名的的那一栏字，能找出该 javax.servlet.ServletRequest 类在多个 jar 包中出现
6：打开 pom.xml 使用 exclusions 标签去除掉重复的 jar 包
如果不是你要答辩，这么基础的问题我是不可能回复的
2020-06-05 15:03
@山东小木 密码 hash 只需要下面的方法就足够了：
String salt = HashKit.generateSaltForSha256();
password = HashKit.sha256(salt + password);
上面的用法是非常专业的方式，并不需要二次 hash。
最核心是下面几点：
1：一定要使用随机盐，用于防止彩虹表攻击
2：使用 sha256 而不是 md5，用于防止 hash 碰撞攻击。md5 已被中国数学家王小云破解，不再安全
3：sha512 更安全但hash值太长，sha256 足够安全 hash 值不是太长。所以 sha256 是最优方案。如果你的系统不是银行类的，采用 sha256 足够了，否则可以采用 sha512。
4：不要使用自己创造的 hash 算法，除非你是极度专业的该领域的专业人士，否则反而容易被破解。
5：不必使用二次 hash，二次 hash 并不能带来安全性的提升
jfinal club 采用的密码 hash、存储方案建立在作者大量、细致的调研，是十分专业的方案。
2020-06-05 14:31
@xiuxiu-xiuxiu 为啥还在使用如此老的版本？ 强烈建议升级到最新版本，这里有升级文档：
https://jfinal.com/doc/14-1
