Spring 的项目严重依赖注解。 @Repository 注解 在Spring2.0之前的版本中，@Repository注解可以标记在任何的类上，用来表明该类是用来执行与数据库相关的操作(即dao对象)，并支持自动处理数据库操作产生的异常 在Spring2.5版本中，引入了更多的Spring类注解：@Component,@Service,@Controller。Component是一个通用的Spring容器管理的单例bean组件。而@Repository, @Service, @Controller 就是针对不同的使用场景所采取的特定功能化的注解组件。 因此，当你的一个类被 @Component 所注解，那么就意味着同样可以用 @Repository, @Service, @Controller来替代它，同时这些注解会具备有更多的功能，而且功能各异。 最后，如果你不知道要在项目的业务层采用 @Service 还是 @Component注解。那么，@Service是一个更好的选择。 就如上文所说的，@Repository早已被支持了在你的持久层作为一个标记可以去自动处理数据库操作产生的异常(译者注：因为原生的java操作数据库所产生的异常只定义了几种，但是产生数据库异常的原因却有很多种，这样对于数据库操作的报错排查造成了一定的影响；而Spring拓展了原生的持久层异常，针对不同的产生原因有了更多的异常进行描述。 所以，在注解了@Repository的类上如果数据库操作中抛出了异常，就能对其进行处理，转而抛出的是翻译后的spring专属数据库异常，方便我们对异常进行排查处理。 通过上面的话来看就是如果是数据库持久层的就使用 @Repository 注解就好了。 根据 Spring Data JPA 的项目，我们会首先定义一个接口，在这个接口上可能会继承 CrudRepository。 如下面的代码： @Repository public interface VisaCheckeeRepository extends CrudRepository<VisaCheckee, Long> { VisaCheckee findVisaCheckeeByCheckeeVisaId(String checkeeVisaId); } 上面的代码中，就算不使用 @Repository 也是可以被扫描到的。 当然我们还是建议使用 @Repository 来注解这个与持久层有关的访问。 如果你还有实现类的话，也记得把你的实现类用 @Repository 注解上。     如果，我们来看看上面的图，就能比较直观的了解 @Repository 这个注解在 Spring 项目中的地位了。   https://www.ossez.com/t/spring-repository/14075

大家都知道 Spring 严重依赖注解。 实际开发的时候，我们用得最多的可能就是下面几个注解了。 注解 用途 @Component 最最普通的注解，表示这个类可以被注入到 Spring 容器中 。 @Repository 用于数据持久层，有关数据库的操作用这个就没错了。 @Service 用于业务逻辑，从数据库中把数据捞出来，我们总要干点什么吧。这个时候可以用这个注解来标记 @Controller 用 MVC 模式中的 C，主要被用来获得访问数据和对数据的返回，通常 JSON 数据格式的处理和生成，以及访问授权，Token 等都放这里。 其实 @Component 是最基本的，如果你希望注入到 Spring 中，并且使用 Spring 来进行管理。 直接用 @Component 没错。 但具体业务也有很多不一样，因此大部分时候都使用特定的注解。     余下 3 个注解的使用也基本上约定俗成了。 按照大家都使用的约定来就好了。   https://www.ossez.com/t/spring/14076

最近应该项目的需要，需要使用一个工具类来访问数据库。 但是这个工具类又被定义成静态访问了。 我们也需要设置一个静态变量来访问数据库。 @Autowired private static VisaRepository visaRepository; private static VisaCheckeeRepository visaCheckeeRepository;     上面的代码在编译的时候是没有问题的。 但是在程序运行的时候提示空对象异常。     类加载后静态成员是在内存的共享区，静态方法里面的变量必然要使用静态成员变量。 通过日志我们可以非常明确的知道上面异常的主要原因就是因为 VisaRepository 这个变量没有初始化，简单来说就是没有被 @Autowired 上去。 问题和解决 在 Spring 框架中，不能 @Autowired一个静态变量，使之成为一个Spring bean。 这是因为当类加载器加载静态变量时，Spring上下文尚未加载。所以类加载器不会在bean中正确注入静态类。 这个和静态变量这个属性有关的，因为静态变量总是先于 Spring 的 上下文加载。 使用构造函数 其实 IDEA 已经非常明确的建议我们不要使用变量 @Autowired 的方式。 而建议使用构造方法或者 Setter 的方式。 Marks a constructor, field, setter method, or config method as to be autowired by Spring's dependency injection facilities. This is an alternative to the JSR-330 javax.inject.Inject annotation, adding required-vs-optional semantics.     在这个时候，我们只需要简单的将 @Autowired 放到构造方法上。 按照下面这样写就可以了。 private static VisaRepository visaRepository; private static VisaCheckeeRepository visaCheckeeRepository; @Autowired public CheckeeUtils(VisaCheckeeRepository visaCheckeeRepository, VisaRepository visaRepository) { this.visaCheckeeRepository = visaCheckeeRepository; this.visaRepository = visaRepository; } setter 给静态变量加一个 setter 方法，并在这个方法上加上@Autowired。 Spring 就能扫描到AutowiredTypeComponent 的 bean，然后通过setter方法注入。 @Autowired public static void setVisaRepository(VisaRepository visaRepository) { CheckeeUtils.visaRepository = visaRepository; }     定义 2 个变量 可以定义一个静态变量，一个非静态变量。 然后使用 @PostConstruct 注解。 这个注解是 JavaEE 使用的，我们通过注解就知道，这个注解就是在构造方法被执行后下一个执行的方法。 我们可以在这里对我们的静态变量初始化。 @Component public class TestClass { private static AutowiredTypeComponent component; @Autowired private AutowiredTypeComponent autowiredComponent; @PostConstruct private void beforeInit() { component = this.autowiredComponent; } // 调用静态组件的方法 public static void testMethod() { component.callTestMethod(); } } 使用 Spring 的工具类获取 Bean 这个方法就是直接调用 Spring 的上下文工具来获得组件。 AutowiredTypeComponent component = SpringApplicationContextUtil.getBean("component"); component.callTestMethod(); 这个方法实在太麻烦，每一次要用的时候都要调用一次，增加不少容易的代码。 总结 这个问题就是 Spring 的 Bean 在什么时候初始化的问题。 如果没有初始化的话，是没有办法直接调用和自动加载的。 根据官方的提示，不要使用变量上的自动加载，使用构造方法的自动加载就可以了，这个也是官方推荐的方式。   https://www.ossez.com/t/spring-autowired/14074

错误信息如下： java.lang.NullPointerException at com.usvisatrack.common.data.tests.jpa.UserRepositoryTest.testInsert(UserRepositoryTest.java:57) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) 上面的错误信息提示的就是因为 userRepository 为空，我们不能进行数据库有关的操作。 问题和解决 尽管我们在测试中定义了： private UserRepository userRepository; 很显然的是 Spring 没有 Autowired。 主要原因是因为 Spring 的测试严重依赖 Spring。 我们没有对 Spring 进行初始化，是不能进行测试的。 因为我们这个代码是对 JPA 进行测试的，因此只需要在测试代码的最上端添加 @DataJpaTest 这个注解就可以了。     需要注意的就是，对 Spring 进行任何测试，包括测试 JPA 或者 API ，都需要对 Spring 进行初始化。 https://www.ossez.com/t/spring-data-repository/14071

@DataJpaTest 这个注解主要用来在 Spring 项目中测试 JPA 数据源。 默认情况下，带有 @DataJpaTest 注解的测试使用嵌入式内存数据库。 因此 @DataJpaTest 这个注解还是有点坑的。 默认数据库 默认采用的是嵌入的 H2 数据库。 就算你配置了数据库链接，如果你不使用下面的注解的话，@DataJpaTest 还是会使用配置的默认数据库。 使用注解： @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) 来让你的程序只使用你提供的数据库连接来进行连接。 事务 @DataJpaTest 具有事务性，会自动回滚插入数据。 如果你的不进行配置的话，你会发现你插入的数据没有办法在数据库中出现。 解决办法就是在方法中，提供 @Commit 注解。 然后再对数据库中的数据进行校验，这个时候数据是不会回滚的。 从日志中，我们也可以看到，插入的数据被回滚了。     当我们提供 Commit 这个注释后，在日志中明确的提示已经提交了。     表 hibernate_sequence 这是因为我们在数据库实体类配置的时候，没有指定主键策略。 在默认情况使用的是 Auto。 如果使用 Auto，Hibernate 将会使用 Oracle 的方式来自增的。 如果需要使用 Mysql 的话，你的实体类需要将主键策略修改为： @GeneratedValue(strategy = GenerationType.IDENTITY) 因为我们实体类使用了继承 AbstractPersistable。     因此我们可以通过修改 application.properties 来实现。 将参数设置为 false spring.jpa.hibernate.use-new-id-generator-mappings=false     这样就会对主键的策略进行修改了，我们就可以避免上面的这个问题了。   https://www.ossez.com/t/datajpatest/14070

提示的错误信息为： Caused by: java.lang.IllegalArgumentException: LoggerFactory is not a Logback LoggerContext but Logback is on the classpath. Either remove Logback or the competing implementation (class org.apache.logging.slf4j.Log4jLoggerFactory loaded from file:/C:/Users/yhu/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.8.2/log4j-slf4j-impl-2.8.2.jar). If you are using WebLogic you will need to add 'org.slf4j' to prefer-application-packages in WEB-INF/weblogic.xml: org.apache.logging.slf4j.Log4jLoggerFactory 错误界面如下：     问题和解决 这个又是典型的 Spring Boot 版本冲突的问题。 在 Pom 文件中，可能有 Log4j 的包。 这个会导致 Spring Boot 没有办法绑定日志。 在我们的项目中就是因为绑定了下面的版本而导致的错误：     如果我们上面的内容从 Pom 文件中删除后，问题解决了。   https://www.ossez.com/t/spring-boot/14069

启动 Spring 项目的时候提示下面的错误信息： Exception in thread "main" java.lang.IllegalArgumentException: Cannot instantiate interface org.springframework.context.ApplicationListener : org.springframework.boot.context.logging.LoggingApplicationListener at org.springframework.boot.SpringApplication.createSpringFactoriesInstances(SpringApplication.java:461) at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:443) at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:436) at org.springframework.boot.SpringApplication.<init>(SpringApplication.java:267) at org.springframework.boot.SpringApplication.<init>(SpringApplication.java:245) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1317) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1306) at com.usvisatrack.common.data.Application.main(Application.java:18) Caused by: java.lang.NoClassDefFoundError: org.springframework.context.event.GenericApplicationListener at java.base/java.lang.ClassLoader.defineClassImpl(Native Method) at java.base/java.lang.ClassLoader.defineClassInternal(ClassLoader.java:466) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:427) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:1110) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:898) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:806) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:764) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:1074) at java.base/java.lang.Class.forNameImpl(Native Method) at java.base/java.lang.Class.forName(Class.java:417) at org.springframework.util.ClassUtils.forName(ClassUtils.java:284) at org.springframework.boot.SpringApplication.createSpringFactoriesInstances(SpringApplication.java:454) ... 7 more Caused by: java.lang.ClassNotFoundException: org.springframework.context.event.GenericApplicationListener at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:766) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:1074) ... 21 more 下面的界面为错误的信息：     问题和解决 上面的问题简单来说就是在你的 Spring 项目中有 2 个版本的 Spring ，你需要找到 Maven 的配置文件中确定只有一个 Spring Boot 的版本。 找到你的 pom配置文件，确保只有一个 Spring Boot 在你的配置文件中。     我的情况是上面老的 spring-context 和新版本的 Spring Boot 冲突了。 删掉上面的依赖就可以了。 https://www.ossez.com/t/spring-loggingapplicationlistener/14067

在本文章中，我们将会解决在 Spring Boot 运行测试的时候，得到 NoSuchMethodError 和 NoClassDefFoundError 的 JUnit 错误。 这个错误的原因，通常是因为我们的系统中有 2 个不同的 JUnit 版本，在运行的时候 JUnit 不知道使用哪个版本来运行。 同时，也有可能是因为 JUnit 测试运行使用的的版本和框架运行的版本不同而导致的。 错误的界面如下     Spring 项目中的 JUnit NoClassDefFoundError 错误 让我们假设我们的 Spring Boot 项目中使用的 Boot 版本为 2.1.2。 基于上面的 Spring Boot 版本，我们可以使用的 JUnit 测试的版本为 5.3.2，这个版本就是 spring-boot-test 项目中使用的依赖。 假设，现在我们还是希望使用 Spring Boot 2.1.2. 但是，我们希望使用 JUnit 5.7.1 版本来进行测试。 一个可行的办法就是在你的 POM.xml 文件中添加 junit-jupiter-api, junit-jupiter-params, junit-jupiter-engine, 和 junit-platform-launcher 依赖。 需要添加的代码如下： <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-api</artifactId> <version>5.7.1</version> <scope>test</scope> </dependency> ... 如果这个时候，你尝试运行测试的话，你将会得到 NoClassDefFoundError 错误： [ERROR] java.lang.NoClassDefFoundError: org/junit/platform/commons/util/ClassNamePatternFilterUtils 如果你不想使用 5.3.2 的版本，想升级到 JUnit 5.4.0 版本，当你再次运行测试的时候，我们还是会得到 NoClassDefFoundError 和 NoSuchMethodError 错误。 错误原因 不管你使用 JUnit 的何种版本，只要你使用的版本和 Spring Boot 中使用的版本不一致的话，我们都会得到 NoClassDefFoundError 这个错误。 这个错误的主要原因是我们的 classpath 中最后有 2 个不同版本的 JUnit。 我们的项目使用的是 JUnit (5.7.1) 版本进行编译的，但是在运行的时候使用的 (5.3.2) 这个版本来运行的。 上面的情况的结果就是 JUnit launcher 尝试用老版的 JUnit 版本中不存在的类来运行。 知道上面的原因后，我们下面来看看可以使用的一些修复方法。 主要解决思路就是让整个项目中只有一个 JUnit 的版本。 修改办法 - 重写 Spring Boot 中使用的 JUnit 这个可能是最有效的方法了。 Spring Boot 可以让你调整属性文件中的版本配置来配置使用不同的版本，你只需要简单的调整 pom.xml 中的版本属性中的版本号，就可以让 Spring Boot 来使用你指定的版本了： <properties> <junit-jupiter.version>5.7.1</junit-jupiter.version> </properties> 如果你的 pom 文件中没有这个属性的话，添加一个就可以了。 然后将下面的内容添加到你的 pom 文件中，在这里我们只需要一个 junit-jupiter 就可以了。 <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter</artifactId> </dependency> 上面的配置将会包含 junit-jupiter-api, junit-jupiter-params, 和 junit-jupiter-engine. junit-platform-launcher 依赖，通常只是在编程运行 JUnit 的时候需要。 针对 Gradle project 的项目，我们可以使用下面的属性配置 ext['junit-jupiter.version'] = '5.7.1' 针对其他的项目 在上面的部分，我们了解了如何在 Spring Boot 中来修正 NoSuchMethodError 和 NoClassDefFoundError 错误，这个错误在 Spring Boot 中属于比较常见的错误。 如果是其他不使用 Spring 的 Maven 项目，我们也可以通过上面的方法来修改冲突。 和 Spring Boot 中的修改方法是一样的，通常都是因为版本冲突的原因导致的。 我们可以通过分析 Maven 中的依赖来找到冲突的版本进行版本调整就可以了。 结论 在本文章中，我们对 Spring 常见的 NoSuchMethodError 和 NoClassDefFoundError JUnit 错误进行了一些阐述，并且针对这个问题提供了解决方案。   https://www.ossez.com/t/spring-boot-junit-nosuchmethoderror/14066

首先需要确定的是你的系统中已经安装了 JDK 可以输入 java -version 命令进行查看。     然后可以通过项目的配置 JDK 进行查看。     更换 JDK 版本 选择上面的添加 JDK 版本，然后选择 IBM Semeru 在你本地计算机上的安装路径即可。 可以看到添加的版本为 IBM-11 的版本。     如果只想在计算机中保留一个版本，可以将其他的版本删除掉。 单击应用即可。 如果你的老项目已经设置了 JDK，你需要对每个项目使用的 JDK 都进行更改才可以。 随后，我们用几个老的项目跑了编译和测试，完全没有什么问题。 https://www.ossez.com/t/intellij-idea-ibm-semeru-jdk/14062

可以访问：IBM Developer 来下载。 在界面中，选择你需要的版本和操作系统。 semeru 有认证版和非认证版，主要是因为和 OpenJ9 的关系和操作系统的关系而使用不同的许可证罢了，本质代码是一样的。 在 Windows 下没有认证版，直接下开源版就行。     可以下载 msi 包，让安装程序直接进行配置。 运行安装程序 双击安装程序，进行安装。 同意许可证 设置相关环境变量 这里可以选择让安装程序设置 JAVA_HOME 环境变量和覆盖 Oracle 安装程序在 Windows 中创建的键值。 如果你的操作系统中安装了多个 JDK 的话，建议不要让安装程序设置你的 JAVA_HOME 你可以自己进行设置。 下一步继续安装。 获得管理员权限进行安装 安装需要管理员权限，在这里单击下一步继续。 安装进程 完成安装 校验安装 运行 java -version 来查看安装的版本。 C:\Users\yhu>java -version openjdk version "11.0.16" 2022-07-19 IBM Semeru Runtime Open Edition 11.0.16.0 (build 11.0.16+8) Eclipse OpenJ9 VM 11.0.16.0 (build openj9-0.33.0, JRE 11 Windows 11 amd64-64-Bit Compressed References 20220804_420 (JIT enabled, AOT enabled) OpenJ9 - 04a55b45b OMR - b58aa2708 JCL - ab74d97849 based on jdk-11.0.16+8) 通过上面的代码你可以看到安装的 JDK 和 JVM 的信息。 你可能不知道程序具体安装到哪里去了。 你可以输入 PATH 进行查看。 默认的安装路径为：C:\Program Files\Semeru\jdk-11.0.16.8-openj9 你可以为你的操作系统设置 PATH 和 JAVA_HOME 环境变量。     我的计算机中还注册过 RedHat 的 JDK，在这里我们可以删除掉，只保留一个，以避免冲突。 在变量在用户的环境变量中进行设置。     至此，Semeru 在 Windows 的安装配置已经完成了。   https://www.ossez.com/t/ibm-semeru-windows/14061