2019-01-16 11:26
@JFinal从入门到放弃 单步调试跟踪一下，这类问题是无法通过猜测得到答案的，看现场的话分分钟就解决了
2019-01-15 18:34
异常提示已经很清楚，配置文件没有找到：D:\workspace\jfinal-share\out\artifacts\share\WEB-INF\classes\/quartz/quartz.properties
2019-01-15 12:04
context path 是一个可以变动的值，也可以是空字符串值 ""。
具体是什么值取决于配置成 context path 为什么值，例如在 tomcat 中配置 server.xml 指定 context path
还有一种情况是不需要配置，将项目放到 tomcat 的 webapps 下面，则项目的目录会自动成为 context path 值
以上这些都是 jfinal 无法干预的，因为 jfinal 仅仅只是很机械化地去取这个值，而不能控制这个值是什么
2019-01-15 11:57
这种细节问题单步调试即可
调试时看变量的 id ，如果 id 相同则证明是同一个对象
这里所说的变量 id 是指 JVM 在创建对象的时候为其指定的一个值，与你的变量本身无关
2019-01-15 11:39
新版本的 Controller 中有一个 renderToString(...) 方法，应该可以简化你目前的需求，感谢分享
2019-01-15 11:37
现在的大部分 paginate 方法是支持 SqlPara 参数的，所以这个问题应该不存在，直接用上 SQL 动态模板就好
如果确实存在不支持的地方，可以从 SQL 模板中拿到 SqlPara，然后再通过 sqlPara.getSql() 拿到 sql， 最后通过下面的方式将 sql 拆分成可用的两个分页的 sql ：
String[] sqls = PageSqlKit.parsePageSql(sql);
其中的 sqls[0] 与 sqls[1] 可用于 paginate 的两个参数
2019-01-15 11:34
写个 main 方法用纯 JDBC 连一下试一试，或者用单步调试，看程序是在哪行代码卡住的
2019-01-15 11:31
model 内部有几个简单的带 cache 的查询方法，可以用一用
加二级缓存会让复杂度提升很多，jfinal 对此很谨慎
还有一个重要原因是，jfinal 在理念上并不认同在 model 层或者叫 dao 层使用二级缓存，jfinal 缓存的应用原则有：
1：缓存尽可能在上层去做，例如在 controller 层之前使用拦截器
2：缓存尽可能对开发是透明的，例如拦截器自动化搞定，不需要人为干预
第一个原则可以最大程序提高性能，因为越是往上层离客户端越近，缓存的粒度越大。
第二个原则减少耦合，有利于可读性和可维护性
2019-01-15 11:26
JBolt 让开发更快速，进一步节省用户时间，值得拥有，赞
2019-01-15 11:24
Caused by: java.lang.OutOfMemoryError: Java heap space
JVM 分配的内存被占满了， 找到那个耗内存的代码，改之即可
