2016-12-02 10:38
典型的配置问题，普通 java 项目的类路径有的在 bin 目录下面，而 web 类路径在 WEB-INF/classes 之下，那么在用 main 方法启动的那个时刻用的是 bin下面的 class，而 web被加载时使用的是 WEB-INF/classes 下面的 class
结果就是看似完全一样的类文件，分别来自不同的地方，造成加载异常
又扫描了一下你的贴子，这个异常是说工不到 class 文件，比上面我提到的情况还要基本， Default Output folder 没有配置好而已，看一下手册，里面有详细的图文并茂的配置
2016-12-01 18:23
如果用数据库客户端，例如 Navicat 这种工具查询仍然很慢，那么就先将 sql 调整好，确保 sql 是快的了，再将 sql 移到项目之中即可打完收工了
2016-12-01 18:22
99.9% 的可能性是 sql 本身就慢，定位这个问题很容易，先不用 jfinal 去查库，而是将 sql 放在数据库客户端中手动先查询一下，看查询返回值所花时间即可
2016-12-01 18:15
这件事情的学名叫：mass assignment，是任何框架都存在的事情，即便你用Spring、struts开发，或者用 ruby 语言的 rails框架开发也一样要处理这件事，开发者自己需要处理好，因为web 框架处于后端，在框架层面无法预测你前端页面传过来的哪些字段是需要的，这种“哪些字段是需要的”逻辑属于业务层面的事情
jfinal 在很早期的版本就已提供了极简支持：
1：model.keep(...) 可以在 getModel 以后，指定只保留几个属性，可以一次指定多个，如：model.keep("title", "content")
2：model.remove(...) 也可以移除指定的属性
对于这个问题的探讨，几年前就有了：http://www.oschina.net/question/260040_46570
2016-12-01 17:23
jfinal 在所有操作数据库的地方都用了 finally { conn.close(); } 确保连接被关闭，所以只要是直接使用 jfinal API 操作数据库，都确保了连接关闭
连接可能未被关闭的情况是开发者自行获取 Connection 的情况，例如：
DbKit.getConfig().getConnection() 或者
DbKit.getConfig().getDataSource().getConnection()
上述两类代码，开发者需要自行处理 connection 的关闭，建议一定要在 finally 块之中去关闭
至于贴子中出现的问题，除了上述用户自行去拿 connection 没关的情况，还有一种情况是连接获取的速度快于连接回收的速度，造成连接很快被耗尽的情况，调整下连接池大小，以及程序即可
2016-12-01 17:03
注意一下，关键在于创建 RedisPlugin 对象时，传入不同的 cacheName 时，要连接到不同的 reids 服务端程序，通常 ip 地址是不同的
2016-12-01 17:02
RedisPlugin 使用 cacheName 是指连到不同的 reids 服务端的通道，或者连到同一个 redis 的多个连接，这多个连接可能连接到了不同的 db
贴子中的代码如果表现出了覆盖的行为，肯定是 bbs 与 news 这两个 cache 配置到了同一个 redis 服务端的同一个 db，改成配置到不同的 redis 服务端或者同一个 redis 的不同 db 即可
2016-12-01 13:29
方言设置：arp.setDiaect(SqlServerDialect())
如果用了生成器，也要设置：generator.setDialect(new SqlServerDialect())
2016-12-01 10:21
状态是 200，但你的期望是出错应该返回 500 或 404，前提是真的有异常，并且异常并没有被 catch 块给吃掉，如果你在拦截器中有 catch 块，需要再次将异常抛出，jfinal 才会向客户端返回非 200 的状态
此外，如果希望自己设置状态，可以使用 getResponse().setStatus(number)
2016-11-30 21:43
@nbjgl jfinal 为了让开发环境中的 jetty 使用体验更好，会让开发者在重启项目以后仍然可以保持住 session，就是以避免在开发类似于后台管理类项目时频繁去输入用户名和密码去登录，所以将 jetty 设置成为了重启前持久化 session 到硬盘
而这个 jetty 对session 中的数据持久化时，要求被持久化的对象是可以被序列化的，而这个 Log4jLog 对象无法被序列化，所以报这个异常
在生产模式下根本不会存在这个问题
