2017-03-24 17:54
@zhaozhihong configName 为 main 的是默认数据源,如果你只有一个数据源,那么这第一个也会默认成为主数据源
不要使用 model.dao.use(...),而是要直接 model.use(...) , 这样就没问题了,最终是: model.use(...).find(sql)
通常要封装得更好,可以利用一个全局拦截器,在拦截器中使用一个 ThreadLocal 去存放当前请求该有的 configName,然后在查询的时候,统一使用:
Db.use(Kit.getConfigName()).find(sql, ...) 或者
model.use(kit.getConfigName()).find(sql, ...)
2017-03-24 17:49
@wyntergreg 我这里也是 IDEA 下用的 cos,一点毛病没有,只能说是人品问题了,哈哈
尝试重新创建项目,多半还是配置问题,大家都用得好好的,没毛病
2017-03-24 17:48
这个业务层场景最好是直接在业务层中直接写代码去做验证,验证失败返回一个jfinal 提供的 Ret 对象,然后 renderJson(ret) 即可,俱乐部的 jfinal-club 中有大量的这种用法,非常方便
如果一定要用拦截器,建议如下方法:
1:将 CheckKeyInterceptor 拦截器直接用于业务层,而非控制层
2:业务层的 getCardInfo(...) 使用 User 为形参
3:在 CheckKeyInterceptor 之中通过 inv.getArg() 可获取到 User 参数值,对该值进行验证即可
4:此方法的缺点是你无法在业务层拦截器中直接 renderJson()
如果你希望在拦截器中直接 renderJson 建议采用如下办法
1:仍然使用控制层拦截器
2:在拦截器中通过 inv.getController().setAttr("user", user) 将对象传到控制器
3:控制器中通过 getAttr("user") 得到 user
4:控制器调用业务层时直接传入 user 对象
注意:以上两种办法都需要将业务层改造为传递 User user 形参,而不是 Controller 形参
注意:控制层到业务层只能是单向依赖,不能让业务层去依赖于控制层,所以 EcardService.addLogin(this) 是绝对不可以的,这种依赖方式缺点很多,例如,将来无法将业务层重用于其它场景
2017-03-24 17:35
@ghostsf 既然自己 try catch 住异常,那自然是业务范畴,否则不必 try catch 它,而是让 jfinal 框架自行处理
2017-03-24 11:36
@wyntergreg 你是怎么部署的? 打成 war 包,然后将 war 直接扔进去的? 此外,你说的 tomcat 发布目录的 lib 下面没有 jar 包,是指项目的 WEB-INF/lib 还是指 tomcat 的 lib ?
2017-03-24 11:34
@heijie730 微信开发需要更换 jdk 中的一个 jar 包,这事你知道吧? 注意要换上
此外,如果是 tomcat 部署注意一些坑:https://my.oschina.net/jfinal/blog/353062
最后,可以非常确定的说,这事跟 tomcat 没有关系,本站部署的 jfinal weixin 1.8 起码有半年以上了,极其稳定,非常好使
2017-03-23 17:47
@wyntergreg 我相信,归根到底还是一个配置的问题, IDEA 的配置一定要了然于心,与 eclipse 有很大的不同,注意 pom.xml 中要是 compile 不能是 provided