2017-09-15 11:53
如果接收取决于客户端采用什么方式发送数据，例如是普通表单提交还是 multipart 提交，前者用 getPara(...) 即可，后者用 getRequest().getInputStream() 得到 InputStream 以后，从输入流里面获取数据，也可以试试 getFile()
2017-09-15 11:15
@hwy123456 如果是刚研究，强烈建议看一下 jfinal 手册中的 template engine 那一章，节省无数时间
2017-09-15 10:58
好多年不用 jsp 与 jstl ， 没法帮到你
但有一点是肯定的，jfinal 未对 jsp/jstl 做任何干预，是一定可以正常使用的
最后，建议使用 jfinal 默认的模板引擎，节省生命，首页有 jfinal demo 可以下载，里面有实际的例子
2017-09-15 10:56
如果在拦截器中释放，那么你无法阻止别的拦截器得到异常以后不再抛出，那么就无法避免资源泄漏
因此，connection 资源的释放应该越早越好，早释放除了可以避免可能的资源泄漏，还可以提升 connection 的利用效率，在极高并发的时候，很可能是有线程在等待连接池中的空闲连接的
2017-09-15 10:52
@arboret jfinal 手册里面全都有， sql 管理功能用的 jfinal 模板引擎，那么模板引擎中的所有功能可以直接用于 sql 模板之中，例如你的这个 sql，用下面的结构，立即避免掉了java 代码中的 if 判断：
#for(x : cond)
#if(x.key)
#(x.key) #para(x.value)
#end
#end
以上通过一个 #if(x.key) 直接避免掉你在 java 代码中的五个 if 判断，此外，生成sql 语句的 IN(...) 这块代码，也完全可以放在模板文件之中，而 java 代码只需要准备好参数就好
生成 sql 的事情天然就该交给模板引擎来做，你现在的用法是 java 代码中做一部分，模板中做一部分，还不如直接在 java 中做完
2017-09-15 10:20
@arboret 很明显问题出在 sql 模板中的使用，但至始至终你都不出示这段代码。
永远记住：生成 "?" 问号占位的是 #para(...) 指令，而不可能与 "map中的 key" 有任何关系
目前你的解决办法很不优雅，只是在生成了错误的 sql 以后，再用 replace 再补救，与真正正确的道路相差甚远
你的 java 代码中用了很多 if 判断，显然这些判断在 sql 模板中去做会更优雅
总之：一定要先会用 jfinal 模板引擎的基本用法，然后再用好 #para，就可以解决问题
2017-09-14 19:59
sql 与参数弄对就可以了，贴子中的 sql 明显是错误的： and orgId in(?)?
正确的应该是： xxx in (?, ?, ?.... ?) 有多少个参数就有多少个问号，然后参数也要对号入座，参数个数也要完全相同
2017-09-14 17:12
jfinal 没有提供上传到 oss 的功能，更加不会限制 oss 功能
建议先写人小 demo，专门上传文件到 oss 上，搞定后再将代码挪到项目中来
2017-09-14 16:18
arp.setContainerFactory(...) 配置 CaseInsensitiveContainerFactory 的时候，不要给构造方法传入任何参数
2017-09-14 11:24
@aloneJFinal 参数与上传文件本身是被包含在整个 http 封装好的流里面的，解析这个流才能得到参数与文件内容，而一旦解析，文件和参数是同时被解析的，参数存放的位置也是不确定的，或许在文件之中某个位置
