Spring 容器默认的实现类。在遇到Spring bean 相关问题，都会涉及到 DefaultListableBeanFactory，因此列出常用的元素，方便知识梳理和 问题定位。
ApplicationContext Central interface to provide configuration for an application。除了提供标准的BeanFactory能力以外，还实现了ApplicationContextAware、ResourceLoaderAware这样的接口。
ApplicationContext 主要功能是实现通用的context，也是BeanFactory。不同于简单的BeanFactory，还提供了初始化BeanFactory的一些特殊的Bean。我们经常使用的功能，对外提供的方法大部分都委托BeanFactory实现。
BeanFactory最基础的访问bean容器的接口，定义了BeanFactory 的实现标准
ListableBeanFactory主动扫描加载bean示例的BeanFactory定义
<T> T getBean(String name, Class<T> requiredType) throws BeansException;
获取指定Class 的bean 实例。如果不存在，就实时实例化（new Clazz 和 bean-init ）
protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly) throws BeansException
上述 getBean 逻辑的真正实现。bean 获取的核心实现都在这个方法中。
protected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException
Bean 实例化逻辑的真正实现。
creates a bean instance, populates the bean instance, applies post-processors, etc.
protected Object getSingleton(String beanName, boolean allowEarlyReference)
Spring 默认都是以单例模式获取bean。 循环依赖解决方案参考此处的三级 cache。
SpringMVC 从3.2 版本之后，提供了全局 Controller 增强 Advice 特性。框架初始化过程（component scanning）中，针对功能 Advice 和 异常处理分别做了不同的解析。
针对 Controller 的自定义方法
@ExceptionHandler,@InitBinder,@ModelAttribute，如果想应用到全局，可以声明为 @ControllerAdvice
@ControllerAdvice
public class ExampleAdvice {
@InitBinder
void initBinder(WebDataBinder binder) {
binder.addCustomFormatter(new DateFormatter("yyyy-MM-dd"));
}
@ExceptionHandler({FileSystemException.class, RemoteException.class})
public ResponseEntity<String> handle(IOException ex) {
// ...
}
// @RequestMapping methods, etc.
}
复合注解，ControllerAdvice + ResponseBody = RestControllerAdvice
实际上是针对 message conversion 处理的异常进行拦截和增强。
如上，RestControllerAdvice 也属于 ControllerAdvice。因此，框架初始化过程中，只需要识别 @ControllerAdvice 注解的bean。
org.springframework.web.method.ControllerAdviceBean#findAnnotatedBeans
1️⃣ Controller 功能增强
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#initControllerAdviceCache
2️⃣ Controller 异常拦截处理
org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver#initExceptionHandlerAdviceCache
1️⃣ 异常处理分发
org.springframework.web.servlet.DispatcherServlet#processHandlerException
2️⃣ 获取匹配的异常处理方法
org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver#getExceptionHandlerMethod
在实际开发过程中，使用 ControllerAdvice 拦截 SomeFooException， 发现并没有达到预期效果。配置如下代码所示：
// 业务异常SomeFooException 匹配到 handle 方法， 但是异常实例和 handle 入参类型不符合，抛出 IllegalArgumentException: No suitable resolver
@ExceptionHandler({IllegalArgumentException.class, SomeFooException.class})
public ResponseEntity<String> handle(IllegalArgumentException ex) {
// ...
}
通过源代码跟踪分析，在上述 handle 方法反射调用发生异常（入参类型不匹配）。 SpringMVC 无法处理，异常传递给 Tomcat 处理。
/**
* Find an @ExceptionHandler method and invoke it to handle the raised exception.
*/
protected ModelAndView doResolveHandlerMethodException(HttpServletRequest request,
HttpServletResponse response, @Nullable HandlerMethod handlerMethod, Exception exception) {
// 根据异常类型，获取匹配的处理方法，如上述的 handle 方法
ServletInvocableHandlerMethod exceptionHandlerMethod = getExceptionHandlerMethod(handlerMethod, exception);
try {
{
// 反射调用，对 exception 进行异常包装和处理。
exceptionHandlerMethod.invokeAndHandle(webRequest, mavContainer, exception, handlerMethod);
}
}
catch (Throwable invocationEx) {
// Any other than the original exception (or its cause) is unintended here,
// probably an accident (e.g. failed assertion or the like).
if (invocationEx != exception && invocationEx != exception.getCause() && logger.isWarnEnabled()) {
logger.warn("Failure in @ExceptionHandler " + exceptionHandlerMethod, invocationEx);
}
// Continue with default processing of the original exception...
// SpringMVC 无法处理的异常，传递给 Web 容器（Tomcat）处理。
return null;
}
}
不同异常处理的 response
1️⃣ Tomcat 异常处理返回信息。 Http StatusCode = 500
{
"timestamp": "2023-08-03 19:55:03",
"status": 500,
"error": "Internal Server Error",
"message": "foo 必填",
"path": "/example/saveOrUpdate"
}
2️⃣ SpringMVC 自定义异常处理返回信息。 Http StatusCode = 200
{
"message": "foo 必填",
"code": 500,
"data": null,
"timestamp": 1691066025153
}
1️⃣ Advice 未生效首先 check basePackages， 是否包含对应的 Controller。
2️⃣ 全局异常拦截未生效，首先检查异常是否包含、以及匹配的优先级顺序。
## 以管理员身份运行bash
mysqld --remove mysql
mysqld --install mysql5 --defaults-file=D:\\service-experiment\\mysql-5.6.33-win32\\my.ini
启动失败，原因：ini配置文件中添加了slowlog 的配置，但是没有创建对应的日志路径，导致启动报错
[ERROR] Could not open D:\service-experiment\mysql-5.6.33-win32\data\log\mysql_slow_query.log for logging (error 2). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
启动失败，原因：彻底删除了data文件夹，导致mysql内置的数据库找不到，无法启动
[ERROR] Fatal error: Can’t open and lock privilege tables: Table ‘mysql.user’ doesn’t exist
为什么404的错误页显示 Whitelabel-page ? 根据浏览器的网络请求分析，肯定是服务内部跳转处理的。 根据返回Whitelabel 错误页的信息，肯定是spring-boot 处理的错误页 如何跳转的？spring-boot 如何替web容器托管了错误页处理功能？
SpringBoot默认提供/Error映射，它以合理的方式处理所有错误，并在servlet容器中注册为“全局”错误页。对于机器客户端，它将生成一个JSON响应，其中包含错误、HTTP状态和异常消息的详细信息。对于浏览器客户端，有一个“Whitelabel”错误视图，它以HTML格式呈现相同的数据(要自定义它，只需添加一个解析为“Error”的视图)。要完全替换默认行为，您可以实现ErrorController并注册该类型的bean定义，或者简单地添加一个类型为ErrorAttributes的bean来使用现有机制，但替换内容。
对应：Developing Web Applications ➡Spring MVC Framework➡Error Handing
ErrorPageFilter 滤请求并转发请求到 error
BasicErrorController 默认error请求处理
ErrorMvcAutoConfiguration 默认错误注册配置、错误页跳转配置，例如：注册默认ErrorPage，注册 BasicErrorController
ResourceHttpRequestHandler 默认的404错误，就是统一由该Handler 产生
WhitelabelErrorViewConfiguration 我们看到的 spring-boot 默认错误页
ErrorPageFilter 实现web错误页跳转是通过来，非嵌入式应用程序(即已部署的WAR文件)提供。作用是过滤请求并转发到错误页，而不是让容器（例如：Tomcat）处理它们。
private void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException {
// 包装response，支持错误分支判断，包装设计模式
ErrorWrapperResponse wrapped = new ErrorWrapperResponse(response);
try {
// 正常业务执行
chain.doFilter(request, wrapped);
// 如果请求response error（例如：404， 500），该Filter 进行判断转发到错误页
if (wrapped.hasErrorToSend()) {
// 服务内部定向跳转，这样，就请求到 BasicErrorController
// request.getRequestDispatcher(errorPath).forward(request, response);
handleErrorStatus(request, response, wrapped.getStatus(), wrapped.getMessage());
response.flushBuffer();
}
// ...
} catch (Throwable ex) {
// ...
}
}
ResourceHttpRequestHandler 优先判断404问题
public void handleRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
// For very general mappings (e.g. "/") we need to check 404 first
Resource resource = getResource(request);
if (resource == null) {
logger.trace("No matching resource found - returning 404");
// response.hasErrorToSend = true;
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
}
// ...
}
在默认路径下，创建自定义的错误页文件即可
src/
+- main/
+- java/
| + <source code>
+- resources/
+- templates/
+- error/
| +- 5xx.ftl
+- <other templates>
在使用 tk.mybatis组件的过程中，调用 insertList()，报错如题。
表面意思是：没有找到 SpecialProvider 默认构造方法，SpecialProvider 实例化失败。
实际上是：insertList 的 ProviderSqlSource 没有替换 的 DynamicSqlSource，mybatis 直接使用ProviderSqlSource 中的 SpecialProvider 进行解析使用，导致的异常。
tk.mybatis 组件提供的 tk.mybatis.mapper.common.Mapper 是用于通用的DAO 方法的增强，不用重复的写增删改查的代码，后续简称 Mapper。
tk.mybatis 利用mybatis ProviderSqlSource 的特性，通过将模板进行渲染，生成对应mybatis dynamic xml，实现基础增删改查方法的增强。
如上述的问题，MappedStatement 的 ProviderSqlSource 本来应该是在初始化过 程中渲染和替换为 DynamicSqlSource, 由于某种原因，没有执行。最终导致调用insertList()， 直接使用ProviderSqlSource 的SpecialProvider 解析sql，报错。
通过源代码分析，MapperAutoConfiguration 提供自定义的机制，可以手动配置特定的接口，主动进行渲染和替换。
如下配置，声明特殊的接口，让tk.mybatis 完成ProviderSqlSource 到 DynamicSqlSource 的替换。完成增强方法的初始化。
mapper:
mappers: [tk.mybatis.mapper.common.special.InsertListMapper, tk.mybatis.mapper.common.Mapper]
涉及到版本
mybatis.version:3.4.4 mapper.version:3.4.2 mybatis-spring.version:1.3.1 mybatis-spring-boot.version:1.3.0 spring-boot.version:1.5.4.RELEASE