SpringBoot ApplicationListener事件监听接口使用问题探究
更新时间：2023年04月03日 09:33:10 作者：ForestSpringH
这篇文章主要介绍了SpringBoot ApplicationListener事件监听接口使用问题，自定义监听器需要实现ApplicationListener接口，实现对应的方法来完成自己的业务逻辑。SpringBoot Application共支持6种事件监听
终日惶惶，不知归路；一日写起代码，突发奇想，若是在运行时发现自定义上下文的数据丢失，我们该如何解决处理数据丢失的问题？
问题复现一下，大家看下面的代码，观察是否有问题，又该如何解决这个问题：
@RequestMapping("verify")
@RestController
@DependsOn({"DingAppInfoService","CloudChatAppInfoService"})
public class LoginAction {
@Qualifier("ElderSonService")
@Autowired
private ElderSonService elderSonService;
@Qualifier("EmployeeService")
@Autowired
private EmployeeService employeeService;
@Qualifier("UserThreadPoolTaskExecutor")
@Autowired
private ThreadPoolTaskExecutor userThreadPoolTaskExecutor;
private static AuthRequest ding_request = null;
private static RongCloud cloud_chat = null;
private static TokenResult register = null;
private static final ThreadLocal<String> USER_TYPE = new ThreadLocal<>();
/**
* 注意不能在bean的生命周期方法上添注@CheckAppContext注解
*/
@PostConstruct
public void beforeVerifySetContext() {
AppContext.fillLoginContext();
Assert.hasText(AppContext.getAppLoginDingId(), "初始化app_login_ding_id错误");
Assert.hasText(AppContext.getAppLoginDingSecret(), "初始化app_login_ding_secret错误");
Assert.hasText(AppContext.getAppLoginReturnUrl(), "初始化app_login_return_url错误");
Assert.hasText(AppContext.getCloudChatKey(), "初始化cloud_chat_key错误");
Assert.hasText(AppContext.getCloudChatSecret(), "初始化cloud_chat_secret错误");
if (!(StringUtils.hasText(AppContext.getCloudNetUri()) || StringUtils.hasText(AppContext.getCloudNetUriReserve()))) {
throw new IllegalArgumentException("初始化cloud_net_uri与cloud_net_uri_reserve错误");
}
ding_request = new AuthDingTalkRequest(
AuthConfig.builder().
clientId(AppContext.getAppLoginDingId()).
clientSecret(AppContext.getAppLoginDingSecret()).
redirectUri(AppContext.getAppLoginReturnUrl()).build());
cloud_chat = RongCloud.getInstance(AppContext.getCloudChatKey(), AppContext.getCloudChatSecret());
}
.....以下API方法无所影响......
}其中可能令人不解的是controller组件里初始化方法的代码：
public static void fillLoginContext() {
DingAppInfo appInfo = SpringContextHolder.getBean(DingAppInfoService.class).findAppInfo(APP_CODE);
setDingVerifyInfo(appInfo);
CloudChatAppInfo cloudChatAppInfo = SpringContextHolder.getBean(CloudChatAppInfoService.class).findAppInfo(APP_CODE);
setCloudChatInfo(cloudChatAppInfo);
}
public static void setDingVerifyInfo(DingAppInfo dingAppInfo){
if (dingAppInfo.checkKeyWordIsNotNull(dingAppInfo)) {
put(APP_LOGIN_DING_ID, dingAppInfo.getApp_id());
put(APP_LOGIN_DING_SECRET, dingAppInfo.getApp_secret());
put(APP_LOGIN_RETURN_URL, dingAppInfo.getApp_return_url());
}
}
public static void setCloudChatInfo(CloudChatAppInfo cloudChatAppInfo){
if (cloudChatAppInfo.checkKeyWordIsNotNull(cloudChatAppInfo)){
put(CLOUD_CHAT_KEY,cloudChatAppInfo.getCloud_key());
put(CLOUD_CHAT_SECRET,cloudChatAppInfo.getCloud_secret());
put(CLOUD_NET_URI,cloudChatAppInfo.getCloud_net_uri());
put(CLOUD_NET_URI_RESERVE,cloudChatAppInfo.getCloud_net_uri_reserve());
}
}这里可以发现其实就是将一些项目定制的数据灌入我们的静态自定义上下文AppContext的本地线程ThreadLocal<Map<String,String>>对象中去，但是我们知道这个类型可是线程隔离的，不同的线程数据都不同，而我们的每一个请求都是一个线程，势必会导致数据的丢失，所以我们就算是在组件初始化时将数据给进去，下一个请求给进来也是会报出异常的。
解决思路（实际上不是这么解决的，但是也可以这么做，代价是性能耗费高）：
设计一个监听者，一个发布者，在请求进入的方法上进行切面处理，切面检查AppContext对象数据，若为空则发布事件，不为空则进入方法：
事件原型：
public class AppContextStatusEvent extends ApplicationEvent {
public AppContextStatusEvent(Object source) {
super(source);
}
public AppContextStatusEvent(Object source, Clock clock) {
super(source, clock);
}
}监听者：
@Component
public class AppContextListener implements ApplicationListener<AppContextStatusEvent> {
@Override
public void onApplicationEvent(AppContextStatusEvent event) {
if ("FillAppContext".equals(event.getSource())) {
AppContext.fillLoginContext();
} else if ("CheckAppContextLogin".equals(event.getSource())) {
boolean checkContext = AppContext.checkLoginContext();
if (!checkContext) {
AppContext.fillLoginContext();
}
}
}
}发布者（切面类）：
@Aspect
@Component("AppContextAopAutoSetting")
public class AppContextAopAutoSetting {
@Before("@annotation(com.lww.live.ApplicationListener.CheckAppContextLogin)")
public void CheckContextIsNull(JoinPoint joinPoint){
System.out.println("-----------aop---------CheckAppContextLogin---------start-----");
MethodSignature signature = (MethodSignature) joinPoint.getSignature();
boolean value = signature.getMethod().getAnnotation(CheckAppContextLogin.class).value();
if (value){
boolean checkContext = AppContext.checkLoginContext();
if (!checkContext){
SpringContextHolder.pushEvent(new AppContextStatusEvent("FillAppContext"));
}
}
}
@After("@annotation(com.lww.live.ApplicationListener.CheckAppContextLogin)")
public void CheckContextIsNull(){
System.out.println("-----------aop---------CheckAppContextLogin---------end-----");
SpringContextHolder.pushEvent(new AppContextStatusEvent("CheckAppContextLogin"));
}
}那么AOP切面类捕获的是注解：
@Inherited
@Documented
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface CheckAppContextLogin {
boolean value() default false;
String info() default "";
}这里不难发现我们在切面的前置与后置增强方法里都是先检查AppContext数据的完整性，再进行填充数据。这样如果我们每一个请求方法都打上注解@CheckAppContextLogin也可以实现，但是问题是除填充的方法外其他的数据太难维护且切面劫持代理的代价太高，检查数据的频率太高。
正确的解决方案：
根据数据的业务功能划分，因为主要是实现两个对象的填充，哪怕这几个数据丢失了，但是同一个controller组件的成员变量都是同一个对象，且都在初始化的时候进行了初始化，故后续切换请求了也不影响它们实现业务的能力：
private static AuthRequest ding_request = null; private static RongCloud cloud_chat = null;
我们可以在拦截器中要求前端给我们传递当前用户的用户类型与唯一标识，来进行每一次请求的用户定制数据的封装（减少请求内调用方法链查库操作）：
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String token = (String) request.getSession().getAttribute("token");
String user_type = (String) request.getSession().getAttribute("user_type");
if (StringUtils.hasText(token) && StringUtils.hasText(user_type)) {
Context context = new Context();
if (Objects.equals(user_type, "elder_son")) {
ElderSon elderSon = elderSonService.getElderSonByElderSonId(token);
context.setContextByElderSon(elderSon);
return true;
} else if (Objects.equals(user_type, "employee")) {
Employee employee = employeeService.getEmployeeById(token);
context.setContextByEmployee(employee);
return true;
}
} else if (StringUtils.hasText(user_type)) {
response.sendRedirect("/verify/login?user_type=" + user_type);
return false;
}
return false;
}最后千万不要忘记remove一下ThreadLocal的引用：
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
AppContext.clear();
HandlerInterceptor.super.afterCompletion(request, response, handler, ex);
}所以实际场景实际解决，核心是业务，代码简洁只是附带的要求。
到此这篇关于SpringBoot ApplicationListener事件监听接口使用问题探究的文章就介绍到这了,更多相关SpringBoot ApplicationListener内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
这篇文章主要介绍了SptingBoot过滤器Filter的使用详解,Filter属于Servlet规范,并不是Spring独有的,Filter主要用于拦截请求,做一些业务逻辑操作,然后可以决定请求是否可以继续往下分发,落到其他的Filter或者对应的Servlet,需要的朋友可以参考下2023-09-09
这篇文章主要介绍了java实现mp3合并的方法,是Java操作多媒体文件的一个典型应用,非常具有参考借鉴价值,需要的朋友可以参考下2014-10-10
这是一个使用了java+JSP+Springboot+maven+mysql+ThymeLeaf+FTP开发的在线蛋糕销售商城，是一个毕业设计的实战练习，具有线上蛋糕商城该有的所有功能，感兴趣的朋友快来看看吧2022-01-01
这篇文章主要介绍了kafka内外网访问配置方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2023-09-09
解析Mybatis SqlSessionFactory初始化原理
本文主要介绍了Mybatis SqlSessionFactory初始化原理，文中通过示例代码介绍的非常详细，需要的朋友们下面随着小编来一起学习学习吧2021-07-07
在SpringBoot项目中简单使用定时任务，不过由于要借助cron表达式且都提前定义好放在配置文件里，不能在项目运行中动态修改任务执行时间，实在不太灵活。现在我们就来实现可以动态修改cron表达式的定时任务,感兴趣的可以了解一下2022-10-10
这篇文章主要介绍了进一步理解Java中的多态概念,是Java入门学习中的基础知识,需要的朋友可以参考下2015-08-08
这篇文章主要介绍了Java函数式编程(十二)：监控文件修改,本文是系列文章的第12篇,其它文章请参阅本文底部的相关文章,需要的朋友可以参考下2014-09-09
这篇文章主要为大家介绍了Feign自定义重试策略及超时时间详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2023-07-07
这篇文章主要为大家详细介绍了23种设计模式之java装饰者模式，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2017-11-11
最新评论