2018-11-03 14:49
@itdoer jfinal 发布 7 年多以来，不断有人问起这个问题，在不同渠道回复这个问题起码重复过 100 次以上
既然这么关心这个问题，在此仅简要回答一下。自动扫描很多缺点：
1：安全性大大降低。第三方 jar 包中可以放点注解让你扫描成路由，然后就可以很轻松接管你的系统了。回看一下 springboot 项目动不动就上百个 jar 包，你敢确定上百个 jar 包中没给你来点路由注解让你扫描？
2：拖慢启动速度。路由扫描在大概率上慢 100 倍不止，启动速度在生产环境下不算大问题，但是开发环境就不同了，开发阶段启动花 2 秒与启动花 8 秒，这个开发体验是有很大差别的。要知道开发的时候改点东西重启项目是很频繁的，累积下来的时间是很可观的
3：代码量与学习成本双双增加。spring 那种在 action 上添加注解的方式，每个方法上都要来那么一下注解，而 jfinal 非注解方式每个 controller 仅一行代码即可配置一系列的路由。 此外，引入的注解的用法，你也是要花时间学习的，多多少少会有学习成本
4：无法为某个 controller 指定 viewPath
5：不支持 Routes 级别的 AOP，也即无法为某一批 controller 指定拦截器，如果你加入俱乐部得到 jfinal club 项目的话，就会体会到 Routes AOP 的妙处，节省代码无数
6：路由分散不利于统一管理。例如哪天你要重新规范路由，jfinal 在一处统一管理路由，要改下类似于一组 Controller 的 controllerKey 是极为方便的。即便是你只想改个别路由，你也得去找到具体的 controller 去翻找路由，这个时间相对要长。
7：路由分散也不便于统一查看。统一在一处的路由很方便去查看，浏览一下即可对全局路由心中有数，散落在各处的路由你得所有 Controller 全浏览一遍
8：统一的路由便于引导 restful 设计风格，统一路由将一个 controller 引导抽象成一个资源，所以就拥有了统一的资源名称，例如 AccountController 的资源名被引导为一个 "/account"，这样避免了使用注解时的随意行为
简要说一下 jfinal 的路由配置有独有的优点：
1：支持 Routes 级别的 AOP
2：支持 Routes 级别的 baseViewPath
3：支持 Controller 级别的 viewPath
4：极速启动，在启动时一次性初始化，极有可能是目前最快的路由匹配方式
此外，你还谈到了 xml 配置，jfinal 的路由配置与 XML 有关本质的不同，前者是 java 代码，后者是外部文本配置，前者代码量极少，后者代码多且十分繁琐且易于出错
最后，这个问题本质是一个习惯问题，当然习惯确实难以改变，关键要看使用者是不是有一颗开放的乐意尝试新事务的心
2018-11-03 12:50
@杜福忠 没错的，今天周六，经过上午的开发，只剩热加载这一个功能就开发完了
undertow-server 比 jetty 启动速度要快得多了，而且轻量级到了极致
2018-11-03 08:52
单步调试可知，查出来的类型是 Page，那么要使用 @糊搞 介绍的 page.getList() 方法直接获取，而不是强制转换
2018-11-03 08:51
java script 发送的数据仍然会是 key value 键值对，所以还得用 getPara("data") 来获取，这种情况一定要彻底忘记 : HttpKit.readData(getRequest())
拿到数据以后，观察 json 数据格式是否正确，然后再用 FastJson 做 parse 转换
最后 fastjson 是根据 setter 方法来做的转换，所以你的 HomePageInfor 一定要先用 jfinal 生成器生成 setter 方法，生成器在首页的 jfinal demo 中有现成的，改改配置即可使用
2018-11-02 15:18
通过看 jfinal 源码可知 this.getRequest().getParameter("picUrl") 与 getPara("picUrl") 是完完全全等价的，因为 getPara(...) 就是转调的底层的 request.getParameter(...)
建议再单步调试多试几次，确定问题原因
2018-11-02 15:14
@年轻人 因为 TRANSACTION_REPEATABLE_READ 级别的事务并发性能比 TRANSACTION_READ_COMMITTED 要差
事务越是严格，并发度越低，例如最后一个 TRANSACTION_SERIALIZABLE 这个级别是的串行处理请求，也就是请求过来以后，一个一个通过，不允许并发，这个性能就会低到无法忍受
2018-11-02 11:34
很多基于 jfinal 自动扫描路由的扩展可用
建议先试用两天 jfinal 默认的方式，少了注解代码其实更干净
2018-11-01 20:59
要先调用 getFile、getFiles 系列方法，然后才可以调用 getPara、getModel 这类方法，文档中有过说明
注意，如果有拦截器、Validator 也要先在其中调用 getFile、getFiles 系列的方法
2018-11-01 19:45
@JM-java 已经在文档中添加了：http://www.jfinal.com/doc/5-7
感谢你的反馈，后面有同学碰到这个问题就能节省大量时间了
2018-11-01 17:15
@tuxming jfinal 的数据库操作部分仅仅是对 JDBC 进行了一个极薄封装，在本质上就是将你的 sql + para 直接扔给了底层的 JDBC，想要出错都是很困难的，因为 JDBC 是很稳固的
