SpringBoot Web 项目要支持响应数据的自动压缩只需要在 application.properties 中配置 server.compression.enabled=true 即可，默认为 false. 这样对于默认 server.compression.min-response-size=2KB 达到 2KB 大小的响应，并且请求头中有 Accept-Encoding: gzip 或 deflate 就会压缩响应数据。

相关的配置请参考：SpringBoot Server Properties

1. server.compression.enabled: 默认为  false
2. server.compression.excluded-user-agents: 针对哪些 user-agents(逗号分隔) 不压缩，默认为空
3. server.compression.mime-types: 会对哪些响应的 content-type 进行压缩，默认为 text/html, text/xml, text/plain, text/css, text/javascript, application/javascript, application/json, application/xml
4. server.compression.min-response-size: 默认为 2KB

文本数据压缩比可达到百分之七八十，对于节约网络消耗来说是非常可关的，不过要些许 CPU 资源。说完了响应的自动压缩，如果请求数据较大也应考虑对请求进行压缩。比如客户端发送请求时带上 Content-Encoding:gzip, 并且请求内容是 gzip 压缩的。

提示：如果 SpringBoot Web 是放在 AWS API Gateway 后端，那么 AWS API Gateway 会在看到请求头 Content-Encoding 的值为 gzip, compress, deflate, 或 br, 会自动解压缩请求数据，然后转发解压缩后的数据到后端，这时候 SpringBoot Web 无需进行请求数据的解压处理。不过对响应数据的压缩是 SpringBoot Web 要做的，AWS API Gateway 并无该功能。

SpringBoot 默认不支持自动解压缩请求内容，如果手动在 Controller 方法中，可以接收字节数组，然后自行解压缩。比如定义如下的 Controller 方法 Read More

出现此错误的大致环境如下

1. SpringBoot 2.7.17, SpringWeb 项目，所引用入的 spring-webmvc-5.3.30, spring 6 已解决
2. JDK 1.8 或 JDK 17
3. 依赖了 jackson-dataformat-xml:2.12.6 和 jackson-dataformat-cbor:2.12.6, 它会在 RestTemplate 加上 application/xml, application/cbor 等 Accept 类型
4. 代码中用 RestTemplate 调用此应用的 Endpoint, 未设置任何头

后面会详细列出能重现此问题的 pom.xml 配置及 Java 代码

在执行

restTemplate.getForEntity("http://localhost:8080/test2", String.class)

时出现如下错误 Read More

Spring 5.0 发布之时(2017-09-28) WebFlux 是它的一大亮点，即响应式 Web 编程。因为同一时代的 RxJava 2 和 Akka Actor 具备一定的流行度，Spring 5 也来赶这一趟时髦。于是多线程编程大致两种模式

1. CompletableFuture, runAsync, supplyAsync, whenComplete...
2. Obervable, observeOn, subscribe, subscribeOn...

以及 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 规范。

然而随着云计算的普及，基于消息系统解耦合的任务分解让代码变得更清晰，编码中甚至不用考虑多线程的行为，部署方式能解决任务执行的效率。
Read More

为了紧跟 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 到底带来了什么显著的特性呢？

1. 依赖于 Spring 6, 最低 Java 17, 兼容 Java 19
2. 支持生成 GraalVM 本地映像，取代实验性的 Spring Native 项目
3. 最低 Java EE 9 和支持 Jakarta EE 10
4. 依赖从 Java EE 迁移到 Jakarta EE API
5. 升级到 Tomcat 10

从 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 或更新的版本，编译，运行，有问题就改代码。 Read More

当我们直接使用 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 &quot;%r&quot; %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 的访问日志到控制台。有两种方式 Read More

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, 介绍了三个配置项 Read More

写作此篇是作为对 Spring 使用 Cache 解析及使用不同类型的 Cache 一文的补充，该文中提到了自定 CacheManager 及配置 spring.cache.type 来选择自己的 Cache 实例，但对 Spring 是如何确定具体 Cache 实现未作展开。本文将介绍选择 Cache 实现的几种方式

1. 默认选择 Cache
2. 声明 Spring Bean Cache
3. 声明 Spring Bean CacheManager
4. 通过 spring.cache.type 属性选择
5. 引入相应的 Cache 实现依赖

Read More

要在一个 Spring 应用中开启缓存方法返回结果的功能很简单，不需要额外的依赖，相关的的注解  @Cacheable, @CacheConfig, @CachePut, @CacheEvict, @EnableCache 等来自 spring-context 包。默认的的 Cache 实现是把数据存入到 ConcurrentMap 中，所以数据一直在内存中，除非显式的调用被 @CacheEvict 的方法来清理。实际进行数据缓存时会有更复杂的策略，如元素个数，占用内存，过期时间，何时使用磁盘等，而且不同的数据类型应有不同的缓存策略。

因此，除了使用默认的 ConcurrentMap 作为缓存外，还可通过配置属性 spring.cache.type 来使用其他类型的缓存，如 Caffeine, Couchbase, EhCache, INfinispan, JCache, Redis 等，或自定义 CacheManager 来使用 Guava Cache。 Read More

项目中有用到 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 完成定制。 Read More

通常我们注册 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 接口的方法 Read More