2017-03-14 15:00

@小飞象 微服务架构,本质来说就是分布式架构,意味着你要将原来是一个整体的项目拆分成一个个的小型项目,然后利用某种机制将其联合起来,例如要引入服务治理、通信框架等基础设施,而这些工作除了会提升复杂度、提升开发成本、提升部署成本以外,还在一个侧面上拉低了性能,因为分布式结点间的通信与协同比在同一机器上要耗时

因此,很多项目为了提升性能,首先会选择做集群这个路径,集群这个方向做到头,再去考虑做微服务这种分布式架构

所以我个人认为微服务现在很热是被炒起来的,应用场景并不是那么地大,而集群方案只需要一个 nginx 做负载就可以搞定了,简单地多

综上,现在市面上的现成的微服务开源项目并不多,人是倾向于理性的,都会先选择最划算的方案。在 git.oschina.net 上去搜搜应该可以找到一些

2017-03-14 14:51

这个应该是纯前端的问题,任何后端模板引擎,仅仅只是响应一份纯文本的 html 给浏览器而已,注意检查一下是不是有 js 在搞乱

2017-03-14 13:42

if 里面的参数直接写,不用带上 #(...) ,感谢搞定后能回来回复贴子

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文件内的包名有冲突倒是有可能的

2017-03-13 21:05

jdbcUrl 中注意设置一下字符集,例如:
jdbcUrl = jdbc:mysql://localhost/jfinal_demo?characterEncoding=utf8

2017-03-13 19:34

druid 自身有类似于 shutdown 和 destroy 类的方法关闭线程,如果是用的 jfinal 提供的 DriudPlugin,如果通过 me.add(druidPlugin) 过的,jfinal 会自动关闭线程,无需干预

此外,上面的代码之中 thread.stop() 这样的代码并不可靠,这个在网上有很多相关资料,这个方法的不可靠性或许就是你所碰到的有时候出问题,有时候不出问题的根本原因

2017-03-13 19:31

这个问题与包名冲突无关,多试几次就知道了

2017-03-13 17:43

上传图片看不到,可再编辑一下该贴子,重新上传图片。参数可以是中文,但要注意字符集为 utf-8

2017-03-13 17:27

@天涯刀 异常提示仍然是同一个问题

最简的解决办法是将线程给搞成 deamon 的,方法很简单,在 new Thread 的时候,传入一个 true 参数即可

其它解决方案,可以是使用一个控制变量,使线程可以完全退出。回到具体的两个问题:
1:tomcat 不是在启动的时候判断,而是在 shutdown 的时候判断是否有线程没有退出
2:要看你的监听事件的事处理方式,例如,是不是在同一个线程中处理的,如果是独立的线程之中,那么 tomcat 线程继续它自己的 shutdown 线程,而其它非 deamon 线程的停止动作还未完成,那么这个异常仍然会出现