ApiBoot v2.2.5版本无法兼容Hoxton.SR5的SpringCloud Gateway

使用ApiBoot最新发布的v2.2.5版本整合SpringCloud GatewayHoxton.SR5版本时导致项目无法启动,控制台抛出的错误如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
***************************
APPLICATION FAILED TO START
***************************

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

org.springframework.boot.web.embedded.netty.NettyReactiveWebServerFactory.lambda$createHttpServer$0(NettyReactiveWebServerFactory.java:158)

The following method did not exist:

reactor.netty.tcp.TcpServer.bindAddress(Ljava/util/function/Supplier;)Lreactor/netty/tcp/TcpServer;

The method's class, reactor.netty.tcp.TcpServer, is available from the following locations:

jar:file:/Users/yuqiyu/.m2/repository/io/projectreactor/netty/reactor-netty/0.9.6.RELEASE/reactor-netty-0.9.6.RELEASE.jar!/reactor/netty/tcp/TcpServer.class

The class hierarchy was loaded from the following locations:

reactor.netty.tcp.TcpServer: file:/Users/yuqiyu/.m2/repository/io/projectreactor/netty/reactor-netty/0.9.6.RELEASE/reactor-netty-0.9.6.RELEASE.jar


Action:

Correct the classpath of your application so that it contains a single, compatible version of reactor.netty.tcp.TcpServer

从控制台打印的错误信息我们可以发现这是版本不兼容的问题导致的,reactor-netty作为SpringCloud Gateway的重要组成部分之一,为什么会出现版本不兼容的问题呢?

reactor-bom

我们在构建项目时,SpringBoot使用最新发布的v2.3.1,在v2.3.1版本的spring-boot-dependencies固化版本依赖模块内定义reactor-bom的依赖,如下所示:

1
2
3
4
5
6
7
<dependency>
<groupId>io.projectreactor</groupId>
<artifactId>reactor-bom</artifactId>
<version>${reactor-bom.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>

${reactor-bom}占位符对应的使用版本为Dysprosium-SR8,通过查看reactor-bom内定义的依赖列表发现了reactor-netty的踪迹,而它对应的版本为v0.9.8,如下所示:

1
2
3
4
5
<dependency>
<groupId>io.projectreactor.netty</groupId>
<artifactId>reactor-netty</artifactId>
<version>0.9.8.RELEASE</version>
</dependency>

那为什么我们在启动项目时控制台抛出了使用v0.9.6版本的reactor-netty导致不兼容的问题呢?

项目依赖的reactor-netty版本

查看idea开发工具内项目的External Libraries发现,项目编译时使用的reactor-netty的版本确实是为v0.9.6,如下图所示:

SpringCloud Gateway依赖的reactor-netty版本

Hoxton.SR5版本的spring-cloud-dependencies依赖内使用的spring-cloud-gateway版本为2.2.3.RELEASE,我们从GitHub拉取spring-cloud-gateway源码到本地,使用idea工具打开项目并切换到2.2.x分支后发现External Libraries依赖列表内所使用的reactory-netty版本为v0.9.7这是编译spring-cloud-gateway时所依赖的版本

spring-cloud-gateway仓库在GitHub的地址为:git@github.com:spring-cloud/spring-cloud-gateway.git

问题分析

  1. 从上面的分析步骤中我们发现,spring-cloud-gateway编译时所使用的reactory-netty版本为v0.9.7,而v2.3.1版本的SpringBoot所使用的reactory-netty版本为v0.9.8,依赖的版本是支持向下兼容的,所以这样不会出现什么问题。

  2. 但是我们项目在编译时使用的reactory-netty版本却为v0.9.6,版本肯定是不支持向上兼容的,所以才导致了项目启动时控制台打印的不兼容异常。

问题定位

ApiBoot的固化版本依赖api-boot-dependencies内默认添加了SpringCloud的依赖,为了方便项目集成SpringCloud时使用组件,不过这也导致了这个问题的发生。

v2.2.5版本的ApiBoot内集成的SpringCloud版本为Hoxton.RELEASE,要比Hoxton.SR5版本发布的更早,它所使用的reactory-netty依赖版本为v0.9.6

解决问题

既然找到了问题,对症下药,解决起来就容易了,我们只需要把项目中所依赖的reactory-netty版本修改为v0.9.6以上版本即可,在项目的pom.xml内添加如下依赖:

1
2
3
4
5
6
7
8
9
10
<dependencyManagement>
<!--省略其他依赖-->
<dependencies>
<dependency>
<groupId>io.projectreactor.netty</groupId>
<artifactId>reactor-netty</artifactId>
<version>0.9.8</version>
</dependency>
</dependencies>
</dependencyManagement>

分布式任务调度框架ApiBoot Quartz内的两种任务存储方式

前言

Quartz是一款比较优秀的分布式任务调度框架,ApiBoot对其封装之前就有两种任务存储方式,分别是:memory(内存方式)、jdbc(数据库方式),不过我们需要编写一些繁琐的代码配置,ApiBoot实现了集成后,可快速应用到项目中,而且还提供了 ApiBootQuartzService 接口用于操作任务的状态、有效性、新任务创建等,提供了一些常用方法,使用时只需要注入即可,因为该类在 ApiBootQuartzAutoConfiguration 自动化配置类中已经做了实例化。

任务存储

之前有提到Quartz提供了两种任务存储的方式,这两种存在什么区别呢?

  • 内存方式:将任务临时存储到内存中,仅支持单项目部署,项目重启后任务会失效,不支持由调度器控制任务漂移,不建议使用。
  • 数据库方式Quartz提供了多种数据库的所需表结构脚本,它内部通过DataSource来操作数据,支持分布式方式部署、支持任务漂移,项目重启后任务不会丢失,直到任务执行完成后才会被从数据库内清除。

默认方式

ApiBoot在整合Quartz之后将内存方式(memory)作为默认的任务存储方式,默认方式下不需要一行代码的配置就可以实现集成,通过ApiBootQuartzService#newJob方法就可以实现任务的初始化运行,还可以指定OnceLoopCron三种方式的任意一种来运行任务,使用方式详见:分布式调度框架Quartz衍生出的三种任务类型,你用过几个?

数据库方式

Quartz针对不同数据库类型提供了代理接口DriverDelegate,不同数据库类型都会有该代理接口的实现类,而我们平时所用到的则为StdJDBCDelegate,该类内包含了Quartz操作数据库表内数据的全部方法。

数据脚本

Quartz针对不同类型的数据库分别提供了 建表语句,使用时请按照脚本名称自行选择。

ApiBoot Quartz启用数据库方式

启用的方式很简单,只需要在application.yml/application.properties文件内添加如下配置:

1
2
3
4
5
api:
boot:
quartz:
# 配置使用Jdbc方式存储任务
job-store-type: jdbc

注意事项:既然启用数据库方式,那么你的项目中必须要有数据源数据库驱动实例化数据源(实例化DataSource的工作一般是ORM框架来担任,如:ApiBoot MyBatis Enhance)等依赖。

敲黑板,划重点

本章主要介绍了ApiBoot整合Quartz后的任务存储方式配置方式以及提供的不同数据库的对应建表脚本。

如果你对ApiBoot开源框架在使用方面感觉不顺手,欢迎提出您的宝贵 意见,让开源框架走更远的路、服务更多的开发者!!!

OAuth2在内存、Redis、JDBC方式下的多客户端配置

Spring所提供的OAuth2集成策略,支持多种方式存储认证信息以及客户端信息,由于在之前的文章中讲解使用时把知识点进行了拆分,有很多同学不太会组合使用,很多单独问我ApiBoot所提供的OAuth2的整合后,多个客户端该怎么配置?

分布式调度框架Quartz衍生出的三种任务类型,你用过几个?

前言

Quartz内部没有明确的任务类型的概念,在ApiBoot中对其进行封装后才确切的定义了这个概念,可以根据业务场景按需选择适合的任务类型来构建执行的任务。

这种方式整合Quartz你见过吗?

Quartz是一款优秀的任务调度框架,支持内存、JDBC的形式来存储未执行的任务列表,支持多个任务节点同时执行任务,支持任务漂移到不同的节点执行。

Swagger2怎么整合OAuth2来在线调试接口?

前言

Swagger2作为侵入式文档中比较出色的一员,支持接口认证的在线调试肯定是不在话下的,当我们在调用OAuth2所保护的接口时,需要将有效的AccessToken作为请求HeaderAuthorization的值时,我们才拥有了访问权限,那么我们在使用Swagger在线调试时该设置AccessToken的值呢?

使用Swagger2作为文档来描述你的接口信息

接口文档在前后分离的项目中是必不可少的一部分,文档的编写一直以来都是一件头疼的事情,写程序不写注释不写文档这几乎是程序员的通病,Swagger2的产生给广大的程序员们带来了曙光,只需要在接口类或者接口的方法上添加注解配置,就可以实现文档效果,除了可以应用到单体应用,在微服务架构中也是可以使用的,只需要整合zuul就可以实现各个服务的文档整合。

ApiBoot接口服务框架的又一新特性GlobalLog全局日志的使用详解

全局日志是一个什么概念呢?

其实理解起来比较简单,类似于我们平时一直在使用的logbacklog4j这种的日志框架的其中一个功能部分,minbox-logging分布式日志框架目前独立于api-boot-plugins,已经加入了minbox-projects开源组织,之前博客有一系列的文章来讲解了ApiBoot Logging(内部是集成的minbox-logging)日志组件的使用以及极简的配置方式,可以访问ApiBoot 组件系列文章使用汇总了解日志组件的使用详情。

OAuth2使用Redis来存储客户端信息以及AccessToken

使用Redis来存储OAuth2相关的客户端信息以及生成的AccessToken是一个不错的选择,Redis与生俱来的的高效率、集群部署是比较出色的功能,如果用来作为服务认证中心的数据存储,可以大大的提高响应效率。

Redis还支持超时自动删除功能,OAuth2所生成的AccessToken相关的数据在超过配置的有效时间后就会自动被清除,这样也隐形的提高了接口的安全性。

既然Redis可以做到这么好,我们该怎么实现代码逻辑呢?

来看看OAuth2怎么设置AccessToken有效期时间时长

OAuth2所生成的AccessToken以及RefreshToken都存在过期时间,当在有效期内才可以拿来作为会话身份发起请求,否者认证中心会直接拦截无效请求提示已过期,那么我们怎么修改这个过期时间来满足我们的业务场景呢?

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×