2019-08-30 16:32
@reborn797 return false 报错，就要根据异常信息，先去解决这个错误
2019-08-30 16:25
如果你的 wstkCx(...) 方法是业务层，应该是返回一个值，然后 controller 中使用这个值，不要将 controller 传给业务层，这种用法是很不规范的
2019-08-30 16:24
你传入的 BaseController cl 参数，然后对其 cl.renderJson() 可能有问题，单步调试一下
2019-08-30 11:23
@66666666 解决就好， jfinal 几乎所有地方都是可以扩展的，例如 ActionHandler 也可以扩展，这样甚至就接管了整个 jfinal
所有 render 通过 RenderFactory 也可以扩展定制
Db 类的行为也可以通过继承 DbPro 来扩展，极度灵活、强大
2019-08-30 11:19
首页下载 jfinal_demo_for_maven，里面的 model 下面有一个生成器
使用该生成器可以为 model 生成 getter、setter 方法，直接可用，省很多事
使用 jfinal 的 renderJson
2019-08-30 11:13
这个是第三方 cos 的问题，不是 jfinal 内部所能控制的
因此，我升级了 cos 版本，解决了这个问题，升级 cos 到 2019.8 版本即可，具体的改进见 gitee:
https://gitee.com/jfinal/cos/commit/8d26eec61f0d072a68bf7393cf3a8544a1112130
https://gitee.com/jfinal/cos/commit/5eb23d6e384abaad19faa7600d14c9a2f525946a
攻击者是利用请求数据格式不对，在上传文件的过程中让 cos 抛出异常，而 cos 抛出异常以后并没有删掉已经上传的一部分内容
解决思路也就极其简单：
在上传逻辑的最外层用 try catch， 在 catch 块中无条件删除所有已经上传的部分内容
https://gitee.com/jfinal/cos/commit/8d26eec61f0d072a68bf7393cf3a8544a1112130
jfinal 是不可能犯这种低极错误的，但难保第三方出问题， 所以 jfinal 诞生 8 年多以来，坚持让 jfinal 不强制依赖任何第三方，对于在部分可选功能时 provided 使用的第三方，也是极度克制的
基本就是 JDBC、reids、数据库连接池、json、文件上传这些基本功能有一个 provided 非强制依赖
多引入一个第三方，就多一个潜在风险
你再回看一下 spring boot 的引入的大量第三方，是不是细思极恐
spring boot 官方给出的一个啥正事也没干的 demo 居然需要 33 个 jar 包依赖，19 M 的体积，如果要添加 AOP、ORM、Template Engine 等常用功能，jar 量还将大量增加：
https://www.oschina.net/news/107259/jfinal-4-2-released
2019-08-30 10:21
@水利万物而不争 因为 jfinal 的 redis 插件仅仅是个极薄封装，连方法名都与底层的 jedis 是一样的，在源码中给出来了如何查看最全的文档：
/**
* Cache.
* Cache api 添加了中文注释，便于工程师更方便使用，另外还原样保持了
* Jedis api 的方法名称及使用方法，以便于仅仅通过查看 Redis 文档
* 即可快速掌握使用方法
* Redis 命令参考: http://redisdoc.com/
*/
上面的注释来自于：com.jfinal.plugin.redis.Cache.java
为了尽可能减少学习成本， jfinal 依照底层的 redis 原有的方法名、参数来安排 API， 只要原先会用 redis，直接使用 jfinal redis 插件根本不需要学习
2019-08-30 10:18
render 时的错误在拦截器中获取不到，我前面给的方案是获取 controller 以及 interceptor、以及业务层的异常
如果你想获取 render 中的异常，继承 RenderFactory， 覆盖掉其中的 getErrorRender(...) 方法，将其返回的 render 自己定制一下即可，非常容易
最后配置一下：
me.setRenderFactory(new MyRenderFactory());
上面这行代码假定你扩展出来的类是 MyRenderFactory extends RenderFactory
2019-08-30 09:42
日志里面会有这类信息
不建议将这类信息响应到客户端，攻击者可以利用这个功能有针对性攻击，在出异常时响应 500 页面、404 页面即可
如果一定要显示这类异常，做一个全局拦截器即可，大致代码：
try {
inv.invoke();
} catch( Exception e) {
inv.getController().setAttr("errorMsg", e.getMessage());
inv.getController().render("error.html");
}
如果你是希望将错误输出为 json ，可以这样：
inv.getController().renderJson("errorMsg", e.getMessage());
2019-08-29 17:10
大概率是客户端出问题了
做一个 html ，里面放上 input type=file 表单域，测试一下上传功能是否正常
你现在发贴上传的这个异常信就是用的 jfinal + cos 来上传的，用了八年多了，没有问题的
2019-08-29 16:32
jfinal 性能是 spring + mybatis 的 4.56 倍，这里是测试项目链接：
https://gitee.com/jfinal/jfinal-performance
jfinal 模板引擎性能是 freemarker 的 4.27 倍，是 velocity 的 3.42，不仅速度快而且内存占用更小，这里是测试项目链接：
https://gitee.com/jfinal/enjoy-performance
jfinal 4.4 又优化了 enjoy 模板引擎的性能，再次提升了 13% 的性能
比 jfinal 性能低得多的 spring 已被广泛应用，所以，完全不必关心 jfinal 的性能
