2019-10-10 15:12
在 undertow 之下的配置可能是下面这样的：
UndertowServer.create(MyAppConfig.class)
.onStart( builder -> {
builder.setServerOption(UndertowOptions.MAX_ENTITY_SIZE, 1024 * 1024 * 100);
})
.start();
上面的这种配置方式在文档中有过介绍：
https://www.jfinal.com/doc/1-4
tomcat、jetty 都有类似的配置，web server 默认会限定每次提交的数据量的大小，否则攻击者可以无限制提交极大的数据，从而可以大量占用 web server 资源，实现攻击的目的
2019-10-10 15:07
jfinal 比较高的版本提供了一个 getRawData() 方法，已经取代了 HttpKit.readData(...)
getRawData() 的优点是可以反复多次调用，不会抛异常
2019-10-10 15:06
这个必须要先定位乱码的来源， renderJson 大概率不是源头，因为 renderJson 内没有涉及 encoding
2019-10-10 15:05
缺少 c3p0 依赖，不建议使用 c3p0 ， 改用 DruidPlugin， 下载首页的 demo ，里面有实例
2019-10-10 15:00
tomcat 下部署有专门的文档进行了说明：
https://www.jfinal.com/doc/1-7
2019-10-10 14:54
@farce 估计是 JDK 的 bug ，也可能是 JVM 需要是 64 位的
你碰到的异常中 HotSwapWatcher 里面使用到了 JDK 的操作系统的文件系统监听机制
2019-10-10 14:52
@小99 想法有一定道理，但 findOne 也比较容易让用户与 findFirst 联系起来，增加辩别成本
如果添加 findOne ， 那么用户要搞清楚 findOne 与 findFirst 的联系与区别，是需要学习成本的
或许改成别的方法名更好，如果你想到好名字，可以在这里继续反馈
2019-10-10 14:50
大量的 springboot 项目在使用 jfinal 的 active record 模块
jfinal 的 active record 模块早已发布为独立的项目，可以单独引入，可以进一步降低 jar 包的大小：
https://www.jfinal.com/doc/5-15
https://www.jfinal.com/doc/6-10
谢谢分享
2019-10-10 14:48
@cw_11 两个项目的 project name 有影响，在 undertow 启动时通过 configWeb 配置一下 project name
当然，有可能是 deploy name ， 不记得了
2019-10-10 14:47
@老兵 fastjson 在 parse 时除了要传入 Page 类型以外，还要想办法传入 Record 类型，否则 fastjson 处理好了外层的 Page 类型，但 Page 内部的 Record 并没有处理好
查查 fastjson 文档
2019-10-10 14:42
获取参数要使用 getPara、getModel、getBean ， 或者直接使用 action 入参，例如：
public void action(String xxx, Integer yyy) {
}
2019-10-10 12:22
必定是有某个地方配置过同名的 redisPlugin，在 com.jfinal.plugin.redis.Cache.java 的构造方法内设置一个断点立即可知哪里进行了这个动作
