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 没有关系
2017-09-29 18:16
这个是基础问题，看下 wiki 搞定： https://gitee.com/jfinal/jfinal-weixin/wikis/Home
2017-09-29 15:30
如果是用于 web 的模板，可以在页面开头使用 #set(...) 指令，然后页面的其它地方就可以用了，而 sql 管理模块的 #sql 指令之间的变量作用域不同，所以就用不了，只能在 #sql 内部现 #set(...) 现用
2017-09-29 15:29
可以通过 arp.getEngine().addSharedObject(....) 将这些常量变成共享变量，然后 sql 文件中直接使用:
arp.getEngine().addSharedObject("NORMAL", xxx.StatusConst.STATUS_NORMAL);
这样配置以后，就可以在任意 sql 中直接使用了
#set(....) 指令的话，需要在 #sql 中来使用，因为每个 #sql 指令内部的数据是彼此独立的
