当前位置: 首页 > 知识库问答 >
问题:

spring.main.allow-bean-definition-overriding=true是不好的做法吗

曹育
2023-03-14

我正在构建一个Spring Boot Rest API服务器,以将遗留应用程序移植到一个更健壮的框架上。这是我使用这些技术的第一个项目。到目前为止,我已经用2个API构建了一个概念验证,该API回复“Hello World!”在JSON中。一个是开放的,另一个是用oauth2保护的。我已经完成了对安全性的调整,以满足需求。

*************************** APPLICATION FAILED TO START
***************************

Description:

The bean 'org.springframework.transaction.config.internalTransactionAdvisor', defined in class path resource [org/springframework/transaction/annotation/ProxyTransactionManagementConfiguration.class], could not be registered. A bean with that name has already been defined in null and overriding is disabled.

Action:

Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true

[WARNING]  java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run (AbstractRunMojo.java:558)
    at java.lang.Thread.run (Thread.java:748) Caused by: org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'org.springframework.transaction.config.internalTransactionAdvisor' defined in class path resource [org/springframework/transaction/annotation/ProxyTransactionManagementConfiguration.class]: Cannot register bean definition [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=org.springframework.transaction.annotation.ProxyTransactionManagementConfiguration; factoryMethodName=transactionAdvisor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/transaction/annotation/ProxyTransactionManagementConfiguration.class]] for bean 'org.springframework.transaction.config.internalTransactionAdvisor': There is already [Root bean: class [org.springframework.transaction.interceptor.BeanFactoryTransactionAttributeSourceAdvisor]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] bound.
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition (DefaultListableBeanFactory.java:897)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod (ConfigurationClassBeanDefinitionReader.java:274)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass (ConfigurationClassBeanDefinitionReader.java:141)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitions (ConfigurationClassBeanDefinitionReader.java:117)
    at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions (ConfigurationClassPostProcessor.java:327)
    at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry (ConfigurationClassPostProcessor.java:232)
    at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors (PostProcessorRegistrationDelegate.java:275)
    at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors (PostProcessorRegistrationDelegate.java:95)
    at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors (AbstractApplicationContext.java:705)
    at org.springframework.context.support.AbstractApplicationContext.refresh (AbstractApplicationContext.java:531)
    at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh (ServletWebServerApplicationContext.java:142)
    at org.springframework.boot.SpringApplication.refresh (SpringApplication.java:775)
    at org.springframework.boot.SpringApplication.refreshContext (SpringApplication.java:397)
    at org.springframework.boot.SpringApplication.run (SpringApplication.java:316)
    at org.springframework.boot.SpringApplication.run (SpringApplication.java:1260)
    at org.springframework.boot.SpringApplication.run (SpringApplication.java:1248)
    at ca.mycompany.oav.ResourceServerApplication.main (ResourceServerApplication.java:22)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run (AbstractRunMojo.java:558)
    at java.lang.Thread.run (Thread.java:748)

共有1个答案

曾喜
2023-03-14

需要注意的是:通过添加这一点,很难猜测哪个bean将具有优先级,因为bean的创建顺序是由依赖关系决定的,依赖关系主要在运行时受到影响。因此,允许bean重写可能会产生意想不到的行为,除非我们足够了解bean的依赖层次结构。

参考资料

 类似资料:
  • 问题内容: 我们可以为XML中提到的同一个bean ID有重复的名称吗?如果没有,那么我们如何在Spring中重写bean? 问题答案: 任何给定的Spring上下文对于任何给定的ID或名称都只能有一个bean。对于XML 属性,这是通过模式验证来实施的。对于属性,这是由Spring的逻辑强制执行的。 但是,如果上下文是从两个不同的XML描述符文件构造的,并且两个文件都使用,则一个将“覆盖”另一个

  • 构成应用程序主干并由Spring IoC容器管理的对象称为beans 。 bean是一个由Spring IoC容器实例化,组装和管理的对象。 这些bean是使用您提供给容器的配置元数据创建的。 例如,以前面章节中已经看到的XML“bean /”定义的形式。 Bean定义包含称为configuration metadata的信息,容器需要知道以下内容 - 如何创建一个bean Bean的生命周期细节

  • bean定义可以包含许多配置信息,包括构造函数参数,属性值和特定于容器的信息,例如初始化方法,静态工厂方法名称等。 子bean定义从父定义继承配置数据。 子定义可以根据需要覆盖某些值或添加其他值。 Spring Bean定义继承与Java类继承无关,但继承概念是相同的。 您可以将父bean定义定义为模板,其他子bean可以从父bean继承所需的配置。 使用基于XML的配置元数据时,可以使用pare

  • 问题内容: 我正在查看一位同事的代码,但遇到一段类似于以下代码的代码: 我相信没有必要,但我很难证明这一点。如果它更具体(,等等)可能很有意义,但是因为我认为这是不必要的。有人可以给我一些原因,这可能导致什么问题,以及为什么这是不好的做法?还是这个代码可以吗? 问题答案: 该声明是方法合同的一部分。定义合同时,您应始终尽可能 精确 。因此,说是个坏主意。 出于同样的原因,这是不好的做法,因为不好的

  • 问题内容: 过去,我使用以下方法读取大量代码: 这样做是惯例吗? 优点和缺点是什么? 在我看来,这就像完成异常的“ Agent Orange”方式 编辑 处理方法中的预期异常 引发意外异常(一对一) 不在乎错误 那是路要走吗? 问题答案: 你不应该扔。这就是为什么。 Throwable是可抛出的事物层次结构的顶部,由and组成。由于根据定义是由不可挽救的条件引起的,因此将它们包括在方法声明中是没有

  • 问题内容: 我正在开发一个显示图像并播放数据库声音的应用程序。我正在尝试确定是否使用单独的JFrame从GUI向数据库添加图像。 我只是想知道使用多个JFrame窗口是否是一种好习惯? 问题答案: 我只是想知道使用多个JFrames是否是一种好习惯? 坏习惯(坏习惯)。 用户不友好:用户只希望看到一个图标时,会在任务栏中看到多个图标。加上编码问题的副作用。 * 编写和维护代码的噩梦: * 一个模态