2020-06-14 19:52
此外，我并不看好现有的微服务技术体系，成本高、复杂度高。
因此，带头搞微服务公司已经在开始弃用微服务，在开始搞宏服务，也就是在回归成本更合理的老模式：
https://www.infoq.cn/article/o465WFwDXg3mw3I8T3Ae
如果真要搞微服务， kubernetes / k8s 容器技术才是未来的方向，成本低，效率高，可以越过现有 spring 整合的那套微服务技术栈
最后，IT 这个行业服从于 幕律分布 规律，简单来说就是同一赛道第一名到第三名将占据 95% 以上的份额，其它则只能勉强活着
这也就意味着，这个行业绝大多数企业都是中小型规模，也就意味着它们的业务根本没有多高的微服务需求，弄个简单的项目拆分 + 集群就性能过剩了
但很多开发者一味追逐微服务，最后只能吃力不讨好，失败收场。 花费精力学习的大量知识也将被快速淘汰
技术 "品位" 很重要，注意这里的 "品位" 中的 "位"，不是 "味" 道的 "味"
2020-06-14 19:38
@大川 jfinal 是 web + orm + aop 框架，而微服务分布式的范畴，两者在本质上并无关系
所以，你相当于是在问 spring 是否适合微服务。实现微服务的是 spirng 整合的那一套第三方的东西，而并不是 spring 自身
所以，jfinal 是否适合微服务分布式开发这个问题本身是不存在的，因为 jfinal 根本就不涉及微服务的事情。
jfinal 是 web + aop + orm 框架，适合的领域自然是 web 项目，需要操作数据库的项目。
2020-06-14 18:10
@tctc4869
MultipartRequest mp = new MultipartRequest(request);
List files = mp.getFiles();
2020-06-13 18:14
如果用的是 DruidPlugin， 重连是自动的，你在 finally 块中 stop() 了，这会连整个插件都不能用，肯定是不可行的
你要的是重连，而不是 stop() 关闭 ActiveRecordPlugin 让它不可用
2020-06-13 18:13
在 YourJFinalConfig 中的各个方法中添加断点，按 F6 执行断点，看是哪一步慢了
定位瓶颈是关键
目前你给的信息量是猜不出来的，我估计是你的 mac 与 windows 环境不同，就 jfinal 自身来说，这两个操作系统对性能的影响是没有的
2020-06-12 15:27
这个是第三方依赖项目 cos 的改进，该项目不属于 jfinal
只要升级 cos 到是高版本 2020.4 就可以了，即便不升级的话在 jfinal 下也是安全的，因为 jfinal 默认已经阻止了对于 .jsp 文件的直接访问
2020-06-12 11:43
补充一下这里的关键：
1：你修改的是 resources/static 下的 html 静态资源
2：web 服务读取的是 target/static 下的 html 静态资源
3：IDEA 没有打开自动编译，造成 web 服务读取到的并不是最新修改后的版本
这个是 IDEA 的特征
2020-06-12 11:41
@spring0563 html 等静态资源不存在热加载这一说，本身就是实时生效的
你放在 resources/static 这个目录下面未实时生效，应该是 IDEA 的自动编译未打开，从而修改以后在 target/classes/resources 下面的相应拷贝并未发生变化
这个问题肯定是与 jfinal 无关的，IDEA 默认不开启自动编译，从而造成误解
2020-06-12 10:52
@spring0563 jfinal enjoy 模版引擎的热加载是独立支持的，只需要配置：
engine.setDevMode(true)
enjoy 的热加载与别的因素无关，只需要上述配置即可
java 代码的热加载，要配置 undertow.devMode=true
还有一种方案是在 IDEA 下使用 jrebel
2020-06-11 17:19
@月月小赚 jfinal 的 enjoy 模板引擎中的表达式是与 java 表达式直接打通的，有方法就调，有字段就取，极度方便，无需学习
2020-06-10 19:32
@himans 忘了告诉你了， jfinal 4.9 已经改进了这里，已发布到 maven 中心库，可以直接用上了
记得回来反馈一下使用感受
