2020-06-15 22:27
@jfinal爱好者22 下载我上一条回复中链接的文件，可配置扩展来解决
配置以后，保持你以前的用法 redirect(...) 即可
2020-06-15 20:54
@zzutligang 这个方案本来是做到 4.9 中来的，有一个小问题没测试出来，所以不完美，完美的方案需要下载这个用上：
http://free-download.jfinal.com/download/MyRenderFactory.zip
2020-06-15 20:53
@jfinal爱好者22 忘了上次详细回复过这个问题，况且解决方案也有下载：
https://jfinal.com/feedback/1925
下载地址：
http://free-download.jfinal.com/download/MyRenderFactory.zip
2020-06-15 20:51
@阿国 JsonUtils 默认不会将 auto_color 转成 autoColor
估计是你扩展过 JFinalJson，让其支持了驼峰
2020-06-15 20:47
@jfinal爱好者22 当使用 nginx 做代理时，nginx 与用户客户端/浏览器之间使用的是 https 以及端口号 443。 而 nginx 与你的项目之间使用的是 http 与类似 8080 这样的端口
从而，在 jfinal 的 RedirectRender 中所能看到的仍然只可能是 http 与 8080， 而看不到 https 与 443
所以，解决的思路必定是将 nginx 所知晓的 https 与 443 传递到 RedirectRender 中
有了上述的铺垫，解决起来就容易了，首先在 nginx 中添加如下两行配置，将 https、443 这两个值传递给你的项目：
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
然后将线上的 jfinal 最新 RedidrectRender.java 源码复制出来：
https://gitee.com/jfinal/jfinal/blob/master/src/main/java/com/jfinal/render/RedirectRender.java
将复制出来的源码做成一个自己的 MyRedirectRender extends Render{
复制出来的源码放这里
}
使用的时候这样：
render(new MyRedirectRender(...));
当然，你也可以继承 RenderFactory，将你自己的 MyRedirectRender 替换掉 jfinal 自带的 RedirectRender
maven 中心库的 jfinal 4.9 并未完全解决这个问题，线上提交的这个才完美解决。
2020-06-15 20:38
jfinal 的某个版本改变过 configRoute 与 configPlugin 的次序，当前是 configRoute 在 configPlugin 之前执行
而你的代码，可能是在 configRoute 中用到了 configPlugin 中加载的 ShiroPlugin ，而这个时候 ShiroPlugin 还未被加载
解决办法是使用如下配置：
public void configConfigConstant(Constants me) {
me.setConfigPluginOrder(1);
}
setConfigPluginOrder(int) 可以配置 plugin 被调用的次序，默认为 3，你可以配置成 1 或者 2
有关这个方法的使用说明在源码中有：
配置 configPlugin(Plugins me) 在 JFinalConfig 中被调用的次序。取值 1、2、3、4、5 分别表示在 configConstant(..)、configInterceptor(..)、configRoute(..)、configEngine(..)、configHandler(...) 之后被调用，默认值为 3，那么 configPlugin(..) 将在 configRoute(...) 调用之后被调用
2020-06-15 20:31
@穿越123 这个锁，只会在 cacheData 为 null 时被使用，所以对性能不会有任何影响
它的作用是，在 cache 中的数据还未被填充时，如果大量并发请求涌来，会产生雪崩，也就是说，大量请求同时看到这个 cacheData 为 null， 进而同时去查数据库
如果是较耗时的查询，这个时候数据库一般会就崩掉
而这个锁就保障了，cacheData 为 null 时，只有一个线程允许许去查询数据库，其它的等待，而等待的线程被唤醒时，cache 中的数据已填充好，就不必去查询数据库了
要写好高并发多线程代码对基本功要求比较高。 jfinal 源码中有大量精心编写的代码，是提升技术的绝佳资源
但可惜的是，认真读源码的同学并不多
2020-06-15 20:15
@zzutligang 当前比较知名的基于 jfinal 的微服务框架 jboot ：
https://gitee.com/fuhai/jboot
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 项目，需要操作数据库的项目。
