对于mysql而言，关于事务的主要知识点可能几种在隔离级别上；在Spring体系中，使用事务的时候，还有一个知识点事务的传递属性同样重要，本文将主要介绍7中传递属性的使用场景

当我们希望一组操作，要么都成功，要么都失败时，往往会考虑利用事务来实现这一点；之前介绍的 db 操作，主要在于单表的 CURD，本文将主要介绍声明式事务@Transactional的使用姿势

200115-SpringBoot 系列教程 Solr 之查询使用姿势小结 接下来进入 solr CURD 的第四篇，查询的使用姿势介绍，本文将主要包括以下知识点 基本的查询操作 fq 查询 fl 指定字段查询 比较/范围 排序 分页 分组 <!-- more --> I. 配置 在介绍 demo 之前，需要先安装 solr 环境，搭建 SpringBoot 项目工程，具体的环境搭...

Solr 控制台实现数据的增删改查 简单记录一下 solr 控制台的 CURD 的使用姿势 <!-- more --> I. CURD 在 solr 提供的控制台上，提供了完整的 CURD 的支持；然而在实际使用的时候，却不一定能很顺手，特此记录一下 我们测试的 shema 定义如下 {代码...} 1. 添加 进入控制台，选中 Collection, 点击 Documents 我们...

200114-SpringBoot 系列教程 Solr 之文档删除 之前的搜索教程开了个头就没有继续了，现在重新捡回来，至少也把 CURD 的基本操作姿势补全了；本篇主要介绍如何删除数据 <!-- more --> I. 配置 在介绍 demo 之前，需要先安装 solr 环境，搭建 SpringBoot 项目工程，具体的环境搭建过程不细说，推荐参考文档 190510-S...

在第一篇的教程中，我们简单的了解了一下 SpringSecurity 的使用姿势，添加依赖，在application.yml文件中加几行配置，就可以实现一个基本的登录认证；

虽然 http 的提供了一整套完整、定义明确的状态码，但实际的业务支持中，后端并不总会遵守这套规则，更多的是在返回结果中，加一个 code 字段来自定义业务状态，即便是后端 5xx 了，返回给前端的 http code 依然是 200

近期使用 RestTemplate 访问外部资源时，发现一个有意思的问题。因为权限校验失败，对方返回的 401 的 http code，此外返回数据中也会包含一些异常提示信息；然而在使用 RestTemplate 访问时，却是直接抛了如下提示 401 的异常，并不能拿到提示信息

SpringBoot 系列 JPA 错误姿势之 Entity 映射 本篇为 JPA 错误使用姿势第二篇，java 的 POJO 类与数据库表结构的映射关系，除了驼峰命名映射为下划线之外，还会有什么别的坑么？ <!-- more --> I. 映射问题 1. 项目基本配置 首先搭建基本的 springboot + jpa 项目， 我们使用的 springboot 版本为2.2.1.RELEASE，m...

前面介绍了 SpringBoot 整合 Mybatis 实现 db 的增删改查操作，分别给出了 xml 和注解两种实现 mapper 接口的方式；虽然注解方式干掉了 xml 文件，但是使用起来并不优雅，本文将介绍 mybats-plus 的使用 case，简化常规的 CRUD 操作

上一篇博文介绍了 SpringBoot 整合 mybatis 的过程，但是 xml 的方式，总感觉让人有点蛋疼；本文将介绍一种 noxml 的使用姿势，纯用注解的方式来支持 CURD

MyBatis 是一款优秀的持久层框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生类型、接口和 Java 的 POJO（Plain Old Java Objects，普通老式 Java 对象）为数据库中的记录。

SpringBoot 整合 SpringSecurity 之起源篇（零） 本篇为SpringSecurity的第一篇，主要来介绍下什么是SpringSecurity，以及在springboot中如何使用它 <!-- more --> I. 基本知识点 官方文档: [链接] 下面是官方介绍 Spring Security is a powerful and highly customizable authentication and access-control fram...

作为一个主职的后端开发者，在平时的工作中，最讨厌的做的事情可以说是参数校验和接口的版本支持了。对于客户端的同学来说，业务的历史包袱会小很多，当出现不兼容的业务变动时，直接开发新的就好；然而后端就没有这么简单了，历史的接口得支持，新的业务也得支持，吭哧吭哧的新加一个服务接口，url 又不能和之前的相同...

在 spring mvc 中，我们知道用户发起的请求可以通过 url 匹配到我们通过@RequestMapping定义的服务端点上；不知道有几个问题大家是否有过思考

又回到 jpa 的教程上了，这一篇源于某个简单的项目需要读写 db，本想着直接使用 jpa 会比较简单，然而悲催的是实际开发过程中，发现了不少的坑；本文为错误姿势第一篇，Repository 接口无法注入问题

191214-SpringBoot 系列教程自动配置选择生效 写了这么久的 Spring 系列博文，发现了一个问题，之前所有的文章都是围绕的让一个东西生效；那么有没有反其道而行之的呢？ 我们知道可以通过@ConditionOnXxx来决定一个配置类是否可以加载，那么假设有这么个应用场景 有一个 Print 的抽象接口，有多个实现，如输出到控制台的...

我们知道在 spring 中可以通过@Component，@Service, @Repository 装饰一个类，通过自动扫描注册为 bean；也可以通过在配置类中，借助@Bean来注册 bean；那么除了这几种方式之外，还有什么其他的方式来声明一个类为 bean 么？

上一篇博文介绍了@Order注解的常见错误理解，它并不能指定 bean 的加载顺序，那么问题来了，如果我需要指定 bean 的加载顺序，那应该怎么办呢？

在网上查询 Bean 的加载顺序时，看到了大量的文章中使用@Order注解的方式来控制 bean 的加载顺序，不知道写这些的博文的同学自己有没有实际的验证过，本文希望通过指出这些错误的使用姿势，让观文的小伙伴可以知道@Order的具体的应用场景

前面一篇博文介绍了在 SpringBoot 中使用 Filter 的两种使用方式，这里介绍另外一种直接将 Filter 当做 Spring 的 Bean 来使用的方式，并且在这种使用方式下，Filter 的优先级可以直接通过@Order注解来指定；最后将从源码的角度分析一下两种不同的使用方式下，为什么@Order注解一个生效，一个不生效

web三大组件之一Filter，可以说是很多小伙伴学习java web时最早接触的知识点了，然而学得早不代表就用得多。基本上，如果不是让你从0到1写一个web应用（或者说即便从0到1写一个web应用），在你的日常业务开发中不太可能碰到需要手写Filter的场景

关于Web应用的全局异常处理，上一篇介绍了ControllerAdvice结合@ExceptionHandler的方式来实现web应用的全局异常管理；

当我们的后端应用出现异常时，通常会将异常状况包装之后再返回给调用方或者前端，在实际的项目中，不可能对每一个地方都做好异常处理，再优雅的代码也可能抛出异常，那么在 Spring 项目中，可以怎样优雅的处理这些异常呢?

接着前面几篇web处理请求的博文，本文将说明，当出现异常的场景下，如404请求url不存在，，403无权，500服务器异常时，我们可以如何处理

前面介绍了spring web篇数据返回的几种常用姿势，当我们在相应一个http请求时，除了直接返回数据之外，还有另一种常见的case -> 重定向；

之前介绍的几篇redis的博文都是基于单机的redis基础上进行演示说明的，然而在实际的生产环境中，使用redis集群的可能性应该是大于单机版的redis的，那么集群的redis如何操作呢？它的配置和单机的有什么区别，又有什么需要注意的呢？

title: 190831-SpringBoot系列教程web篇之如何自定义参数解析器banner: /spring-blog/imgs/190831/logo.jpgtags:

作为一个常年提供各种Http接口的后端而言，如何获取请求参数可以说是一项基本技能了，本篇为《190824-SpringBoot系列教程web篇之Get请求参数解析姿势汇总》之后的第二篇，对于POST请求方式下，又可以怎样获取请求参数呢

一般在开发web应用的时候，如果提供http接口，最常见的http请求方式为GET/POST，我们知道这两种请求方式的一个显著区别是GET请求的参数在url中，而post请求可以不在url中；那么一个SpringBoot搭建的web应用可以如何解析发起的http请求参数呢？