2017-03-14 16:52
非常有价值的分享，好多 jfinal 小伙伴都问过这个问题，由于 jfinal 3.0 改变了 Routes 内部实现，所以 Shiro 扩展相应也要做点改变，感谢你的分享 ^_^
2017-03-14 15:29
@小飞象 在这里找一下：https://www.oschina.net/search?scope=blog&q=jfinal%20dubbo
2017-03-14 15:00
@小飞象 微服务架构，本质来说就是分布式架构，意味着你要将原来是一个整体的项目拆分成一个个的小型项目，然后利用某种机制将其联合起来，例如要引入服务治理、通信框架等基础设施，而这些工作除了会提升复杂度、提升开发成本、提升部署成本以外，还在一个侧面上拉低了性能，因为分布式结点间的通信与协同比在同一机器上要耗时
因此，很多项目为了提升性能，首先会选择做集群这个路径，集群这个方向做到头，再去考虑做微服务这种分布式架构
所以我个人认为微服务现在很热是被炒起来的，应用场景并不是那么地大，而集群方案只需要一个 nginx 做负载就可以搞定了，简单地多
综上，现在市面上的现成的微服务开源项目并不多，人是倾向于理性的，都会先选择最划算的方案。在 git.oschina.net 上去搜搜应该可以找到一些
2017-03-14 14:51
这个应该是纯前端的问题，任何后端模板引擎，仅仅只是响应一份纯文本的 html 给浏览器而已，注意检查一下是不是有 js 在搞乱
2017-03-14 12:24
@EATI001 这个非常有用，单写一个 share 分享贴出来啊，我收藏一下，好多人要呢。只要将上面的 routes 扩展，与 ShirExt 扩展代码分享出来就齐活了
2017-03-14 12:21
模板引擎只有渲染，没有跳转这个概念，千万不要混淆
此外，你上面的程序是先调用的 #@layout() 然后 layout 中调用了 main，main 中调用 tbody3， tbody3 中又调用了 layout 与 main，这已经形成了死循环，是混乱的，注意改进
2017-03-14 12:18
引入 base path 是为了更加统一的管理上传、下载文件，文件在未来要移动时不需要修改代码，因为只在 base path 之下去玩耍，那么程序中的相对路径是一直固定的，不会跑到别的路径之中去
2017-03-14 12:16
自 jfinal 2.1 开始，对路径相关功能引入了 base path 的概念，也就是说上传、下载有相对应的 baseUploadPath、baseDownloadPath 设定，这个 base path 是固定的，在配置的时候可以使用以 "/" 或 "x:/" 打头的方式指向一个绝对路径
该绝对路径可以设置在项目之外的地方，一旦这个 base path 设置好了，那么文件上传、下载都将在这个 base path 路径之下玩耍
因此，在 getFile(...) 时指令的路径，也只是相对于 base path 的一个相对路径而已，如果确实希望让路径更加灵活，可以尝试下面两种方式：
1：将路径设置在更浅的目录，例如设置为 "/" ，那么在 getFile 时指令目录的空间范围会大，应该可以满足需求
2：在 getFile(..) 以后，通过 renameTo(newPath) 将文件转移到希望的地方
2017-03-14 12:10
jfinal 的 Handler 在本质上就是为了让 web.xml 中干净清爽，并且覆盖掉 filter 的功能
所以，这个方向是对的。用的时候，先了解一下第三方 filter 之中的过滤规则，然后将这个规则放在 Handler 中体现就好了，Filter 中也仅仅是在处理 request、response，而 Handler 中也是在处理这两个东东
此外，还注意一下调用的传递，在 Filter 中是通过 filterChain.doFilter(...) 将本次请求转交给剩下的 filter 的，而 Handler 中是通过 next.handle(...) 将本次请求转交给剩下的 handler 的
2017-03-13 21:07
UserService.java 在 com.tcjweb.services 这个包下面，jfinal 并不存在这样的包，jfinal 的包是这样： com.jfinal.....
所以，如果包名有冲突，不会与 jfinal 的包名有冲突。与你的项目中对其它依赖的 jar文件内的包名有冲突倒是有可能的
