Solon v2.5 更新与兼容说明
致老用户:
感谢一路的陪伴,感谢有你。更感谢无私的代码贡献者,老话讲得好“众人搭柴火焰”,好多关键的特性都是由社区贡献的,这就是开源的伟大。也愿更多的人加入这个生态,使用项目、提交代码、帮助宣传等......为中国人的Java生态,添把砖加瓦。
有Spring这个巨人在,难是真的难啊。网上有个牛人讲得好:“没有难度,就没有出手的欲望”。或许有一天 Solon 也会成为巨人,等另一个后来者对它出手:)
v2.0 发布已大半年了,原有的规划已全部完成。情况汇报:
- 部分名字调整(很大的量)。//在 v2.0发布时就干了这个
- 插件命名规范调整。//在 v2.0发布时就干了这个
- 插件类包命名规范调整。//在 v2.0发布时就干了这个
- 增加响应式支持。//v2.3.x 时完成了
- 增加AOT编译便利支持(用于打包 graalvm native image)。//v2.3.x 时完成了。特别感谢“馒头虫”、“读钓”
这次的 v2.5 中段版本更新,做了两个大胆了尝试:
- 启用新的上下文类名:
AppContext
- 之前我们在群里讨论过改名,还发了 Issue 讨论过。主要是
AopContext
太不正经了。其实在 v2.0 时就想改,但是没想好如何兼容过度(像 Luffy 仓库里,还有几十个插件)。这次终于想好了方案。
- 之前我们在群里讨论过改名,还发了 Issue 讨论过。主要是
@Component
增加自动代理- 不少用户苦于“普通组件”与“代理组件”的差别,常会用错。这个新特性,可以让用户学习曲线缩短。
v2.0 后半段的规划:
- 打磨生态
- 宣传,让更多人知道
- 写书,系统介绍 solon(多多出书,方便学校和培训部安排上。哈哈)
不同的人总会有不同的想法。不管如何,多多支持。曾经支持的、反对的,Solon 都爱你们!(如果可能,说服自己的企业赞助 Solon,助力良性发展)
感谢有你!感谢!
本次为中段版本更新(v2.5.3):
- 增加
AppContext
类 - 调整
AopContext
标为弃用,由AppContext
替代(已做兼容性过度处理) * - 增加
@Component
自动代理特性,即自动识别AOP需求并按需启用动态代理 - 调整
@ProxyComponent
标为弃用,组件统一使用@Component
- 调整
@Around
标为弃用,统一使用 context::beanInterceptorAdd 接口添加拦截器 * - 调整 solon.docs.openapi2 对枚举类型的显示处理
- liteflow 升为 2.11.0
- activerecord 升为 5.1.2
- enjoy 升为 5.1.2
- beetlsql 升为 3.25.2-RELEASE
关于 AppContext 带来的兼容性说明:
- Solon 主仓库所有插件已升级
- 原插件接口
start(AopContext context)
仍可使用- 建议改成:
start(AppContext context)
- 建议改成:
- 如有旧代码
AopContext context = Solon.context()
仍可使用- 建议改成:
AppContext context = Solon.context()
- 建议改成:
- 如有旧代码
@Inject AopContext context
仍可使用- 建议改成:
@Inject AppContext context
- 建议改成:
- 第三方仓库的旧版插件,没用到 BeanWrap::context() 接口的,都兼容
关于 AppContext 带来的不兼容说明:
- 第三方仓库的旧版插件,如有用到 BeanWrap::context()、Solon.context() 接口的会不兼容
- 基于:2.5.3 重新编译即可(可以不用改代码;最好是按上面建议修改代码)
- 如果出现不兼容,可以退回到 2.5.2 或者 2.4.6 并返馈问题
- 一般有不兼容可能的是 orm 的第三方仓库(因为它的适配,可能会调用 BeanWrap::context())
- 为什么这个接口会产生不兼容?
- 因为编译时,会留下它的元信息 AopContext,现在变成 AppContext 了。虽然接口一样,但对不上。