2017-10-03 17:55
@abc222 如果有上传文件，先调用一次 getFile(...) 系列方法，在手册上有红色字体强调过
2017-10-03 09:49
controller 中的 getPara(....) 与 inv.getController().getPara(...) 是完全一样的，因为通过 inv.getController() 就是获取到了 controller
获取到 null，只要观测一下控制台输出的 jfinal action report 的 parameter 一栏有没有这个参数即可，如果没有那么肯定为 null
2017-09-30 12:52
@LongLee力 play framework 在 render 方法中通过抛出异常来终止当前流程，这个显然是非常错误的做法：
1：异常的创建非常耗时间，而且还耗空间。异常机制的设计初衷是用于不正常的情形，很少有 JVM 实现试图对它们的性能做优化，所以创建、抛出异常开销是很昂贵的
2：将异常用于正常的流程控制，在逻辑上和原则上就是错误的，会引发一些不确定的副作用，这点在 java 最重要的经典书《effective java》 的第 8 章有详细的阐述
2017-09-30 11:24
这种问题，任何人都无法回答你，谁也不知道你的项目中具体代码是什么样子，谁也不知道你的代码的走向与具体流程，谁也不知道你项目的上下文环境，从一个简单截图的只言片语中如果能解决问题只有神仙可以办到。只能告诉你怎么通过调试自己去解决问题，调试技能是最基本、最关键的开发者技能
完全可以下一个结论： 不会调试相当于开发从来没有入过门
2017-09-30 11:22
在 DefaultAccessTokenCache 这个类的 set(String key, String jsonValue) 方法，点击鼠标右键，选择 Open Call Hierarch，能找到所有调用这个 set 方法的地方，通过在这些地方设置断点，看一下到底有没有被调用， 调有物时候 key 值是什么
如果从来没被调用过，或者调时候 key 值另有其人，那么不用我多说了吧？
既然都会用单步调试，为何不再深入调试一下呢? 这种基本问题通过调式分分钟之类解决
据估计， set 方法可能调用过，但调用的时候这个 key 值另有其人，而你再调用 accessTokenCache.get(key) 的时候，根本获取不到，key 值不同，当然就获取到不
还有一个最直接、最快速的调试办法，当程序走到第 51 行时，按 F5 调试进入 accessTokenCache.get(...) 方法内部，查看 AccessTokenCache 内部的这个 map 属性，里面的 key : vlaue 一目了然
2017-09-30 11:13
在拦截器中通过 inv.getController().getPara(...) 系列的方法可以获取到各种参数，还可以通过自定义注解传递参数，例如： com.jfinal.plugin.activerecord.tx 包下面的 TxConfig 注解就是这么来用的，参考一下
2017-09-30 11:10
@WJME 刚看了一下 Captcha 源代码，貌似忘了实现 Serializable 接口了，jfinal 3.3 已添加该实现
2017-09-30 11:07
@WJME 序列化的实现与 Captcha 类没有关系，已实现的序列化方式自然已支持 Captcha 类，否则那就太不通用了
2017-09-29 20:40
return 只是控制程序流程，不让程序往下执行了而已，例如，某个 action 中有两个分支，分别使用不同的 render：
public void action() {
if(...) {
renderJson(...);
return;
}
render(....);
}
上面的代码，如果没有 return 的话，后面的 render(...) 会被执行，而这个 render 是不需要被执行的
线程满与这个 return 没有关系
