出现此错误的大致环境如下
后面会详细列出能重现此问题的 pom.xml 配置及 Java 代码
在执行
restTemplate.getForEntity("http://localhost:8080/test2", String.class)
时出现如下错误 阅读全文 >>
Spring 5.0 发布之时(2017-09-28) WebFlux 是它的一大亮点，即响应式 Web 编程。因为同一时代的 RxJava 2 和 Akka Actor 具备一定的流行度，Spring 5 也来赶这一趟时髦。于是多线程编程大致两种模式
以及 PlayFramework 的 Action 方法无论返回 Result 还是 CompletableStage<Result>, 内部都是异步的模式。
Akka Actor 比 CompletableFuture, RxJava，以及本文将要讨论的 Reactor 更高级的是 Akka System 可以分布式部署，Actor 分布在不同的进程，主机上。
那时候业界已行成了一个 Reactive Stream 规范 org.reactivestreams(Publisher, Subscriber, Subscription, Processor), JDK 9 也奈不住寂寞，无法对 Reactive Stream 置若罔闻，在 2017-09-21 发布时加入了 java.util.concurrent.flow 包(Publisher, Subscriber, Processor, Subscription) 作为自己的 Reactive Stream 规范。
然而随着云计算的普及，基于消息系统解耦合的任务分解让代码变得更清晰，编码中甚至不用考虑多线程的行为，部署方式能解决任务执行的效率。
为了紧跟 Spring 6 的步伐，Spring Boot 在 2022 年 11 月 24 日释放了 3.0.0. 当前版本是 3.0.1(2022-12-23)。Spring 6 要求用 JDK 17+, Spring Boot 3 自然也要上 JDK 17+ 才能使用，对于一直死死抱住 JDK 8 不放的要升级到 Spring Boot 3 就是个比较大的挑战。
Spring Boot 到底带来了什么显著的特性呢？
从 Spring Boot 2.x 升级到 Spring Boot 3 的指南请阅官方的文档 Spring Boot 3.0 Migration Guide。Spring Boot 1 的项目还得老老实实的先升级到 Spring Boot 2，如果是早期的 Spring Boot 2，第一步是升级到 Spring Boot 2.7.x， 一步步来，免得步子大了扯到X。再到是把 JDK 换成 17 或更新的版本，编译，运行，有问题就改代码。 阅读全文 >>
当我们直接使用 Tomcat 时，访问日志的配置在 $TOMCAT_HOME/conf/server.xml 中
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
产生的日志文件在 $TOMCAT_HOME/logs 目录中，生成以日期戳进行区分的滚动日志文件，如 localhost_access_log.2022-10-25.txt 等
而在我们使用 Spring Boot Web 时, 默认的嵌入式 Web 应用服务器是 Tomcat，我们可以在 Spring 属性文件中配置是否启用 Tomcat 访问日志(默认不启用)。属性文件中的配置针对的是如何输出访问日志到文件，而我们有时候需要输出访问日志到控制台而不非文件，比如 AWS 上的 ECS 应用，控制台的输出可直接发送到 CloudWatch，这样便于分析日志。
在 Spring Web 中可以用 Interceptor 或 Filter 来记录访问日志，但在请求出错时无法准确显示出响应时间和状态码，毕竟 Tomcat 的访问日志在代码的外层，进出 Controller 方法的输入输出信息也就掌握的更清楚。
本文的任务是探索输出 Spring Boot Web 嵌入式 Tomcat 的访问日志到控制台。有两种方式 阅读全文 >>
SpringBoot Web 应用默认是不启用响应数据的压缩，对大的文本类型的响应数据进行压缩是十分必要的，如 JSON, XML 等应用数据，甚至是 JS, CSS 等。
早先的 Web 应用基本是要配置一个叫做 GzipFilter 之类的东西，然后判断请求的 Accept-Encoding 是否含有 gzip, 再对需要的 Content-Type 响应类型的数据进行压缩。
在使用了 SpringBoot 之后，在碰到有压缩响应的需求的时候，第一件事情应该要想到是否能通过在 application.properties(或 application.yml) 配置就行。于是查阅 SpringBoot 2.7.x 的帮助文档 Spring Boot Reference Document, 搜索关键字 compression，翻几页就能找到 17.3.6. Enable HTTP Response Compression, 介绍了三个配置项 阅读全文 >>
写作此篇是作为对 Spring 使用 Cache 解析及使用不同类型的 Cache 一文的补充，该文中提到了自定 CacheManager 及配置 spring.cache.type 来选择自己的 Cache 实例，但对 Spring 是如何确定具体 Cache 实现未作展开。本文将介绍选择 Cache 实现的几种方式
CacheCacheManagerspring.cache.type 属性选择 要在一个 Spring 应用中开启缓存方法返回结果的功能很简单，不需要额外的依赖，相关的的注解 @Cacheable, @CacheConfig, @CachePut, @CacheEvict, @EnableCache 等来自 spring-context 包。默认的的 Cache 实现是把数据存入到 ConcurrentMap 中，所以数据一直在内存中，除非显式的调用被 @CacheEvict 的方法来清理。实际进行数据缓存时会有更复杂的策略，如元素个数，占用内存，过期时间，何时使用磁盘等，而且不同的数据类型应有不同的缓存策略。
因此，除了使用默认的 ConcurrentMap 作为缓存外，还可通过配置属性 spring.cache.type 来使用其他类型的缓存，如 Caffeine, Couchbase, EhCache, INfinispan, JCache, Redis 等，或自定义 CacheManager 来使用 Guava Cache。 阅读全文 >>
项目中有用到 Spring Security 来控制 API 的访问权限，但对于配置应用它基本上是照葫芦画瓢。至于为什么要调用方法
SecurityContextHolder.getContext().setAuthentication()
并且能从 HttpServletRequest 中得到 Authentication。还有，只要在 Controller 的方法中添加一个带 @AuthenticationPrincipal 注解的参数
public String sampleApi(@AuthenticationPrincipal DecodedJWT decodedJWT) {...}
之后，decodedJWT 便自动有了值，诸如此类的，此前一概模糊不清。
早先配置 spring-security-config 是通过继承 WebSecurityConfigurerAdapter, 覆盖它的 configure(HttpSecurity http) 来配置访问规则等。在 spring-security-config 5.7.x 开始不建议用 WebSecurityConfigurerAdapter, 而是借由 SecurityFilterChain 来配置 HttpSecurity 中的规则 ，或者通过 WebSecurityCustomizer 完成定制。 阅读全文 >>
通常我们注册 Spring Bean 是通过像 @Named, @Bean, @Component, @Service 这样的注解来注册的，或者用更为古老的 XML 配置文件的方式。难免有时候要根据实际业务需求在 Spring 运行期间动态注册 Spring Bean, 比如基本某种形式的配置文件或系统属性来注册相应的 Bean, 这好像又回到了 XML 文件注册方式，也不尽然。
那为什么在运行期还要去注册 Spring Bean 呢，直接 new 对象不行吗？当然行得通，不过这样的话就不能更好的使用到 Spring IOC 的好处了。像待注册的 Bean 构造函数可以直接用到其他的 Spring 对象，或 @Value 引入环境变量，还有 @PostContruct 这样的行为。
最初思考如何注册 Spring Bean 时还是费了不少周折，如今清晰了许多。了当的说，不管是 Spring 初始时还是运行时，注册 Bean 的关键(应是唯一) 入口就是 BeanDefinitionRegistry 接口的方法 阅读全文 >>
Java 1.5(Tiger) 个人认为最为激动人心的两个特性是泛型与注解(Java Versions, Features and History)。泛型自然是不必说了，注解对 Java 世界的改变比泛型伟大的多(现在框架的注解配置)，在 Java 1.5 之前我们只能在 Javadoc 注释中做文章，于是只能用 XDoclet 那样不伦不类的东西。Java 的注解发展到现在几乎可以使用在书写代码时的任何地方，见 java.lang.annotation.ElementType 中的类型，囊括了 TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, ANNOTATION_TYPE, PACKAGE, TYPE_PARAMETER(since 1.8), TYPE_USE(since 1.8)。
Java 1.5 基本确定了注解的基本框架，包括元注解(meta-annotation); 直到 Java 8 又扩展了注解的使用范围，列举如下：
创建类实例
new@Interned MyObject();
类型映射
myString = (@NonNull String) str;
implements 语句中
class UnmodifiableList<T> implements@Readonly List<@Readonly T> { ... }
throw exception声明
void monitorTemperature() throws@Critical TemperatureException { ... }
解析前面 ElementType Java 8 增加的 TYPE_PARAMETER和 TYPE_USE 注解使用新场合。ElementType.TYPE_PARAMETER 表示该注解能写在类型变量的声明语句中。ElementType.TYPE_USE 表示该注解能写在使用类型的任何语句中(如: 声明语句、泛型和强制转换语句中的类型) 阅读全文 >>