Bean-Definition Overriding Exception while centralizing micro-services using JHipster-Registry(Cloud Config Server as central server)

Question

I am currently facing an issue during centralization of micro-service client's configuration in JHipster-registry. I am using file-system approach to centralize configuration (central-config) folder of registry app.

During start-up of micro-service client apps at runtime I am getting this exception as shown below

        ██╗ ██╗   ██╗ ████████╗ ███████╗   ██████╗ ████████╗ ████████╗ ███████╗
        ██║ ██║   ██║ ╚══██╔══╝ ██╔═══██╗ ██╔════╝ ╚══██╔══╝ ██╔═════╝ ██╔═══██╗
        ██║ ████████║    ██║    ███████╔╝ ╚█████╗     ██║    ██████╗   ███████╔╝
  ██╗   ██║ ██╔═══██║    ██║    ██╔════╝   ╚═══██╗    ██║    ██╔═══╝   ██╔══██║
  ╚██████╔╝ ██║   ██║ ████████╗ ██║       ██████╔╝    ██║    ████████╗ ██║  ╚██╗
   ╚═════╝  ╚═╝   ╚═╝ ╚═══════╝ ╚═╝       ╚═════╝     ╚═╝    ╚═══════╝ ╚═╝   ╚═╝

:: JHipster ?  :: Running Spring Boot 2.1.6.RELEASE ::
:: https://www.jhipster.tech ::

2020-09-14 12:09:12.061  INFO 3828 --- [  restartedMain] c.t.g.GlueResourceDataServiceApp         : The following profiles are active: dev
2020-09-14 12:09:16.314  WARN 3828 --- [  restartedMain] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'processorStorageGateway' defined in null: Cannot register bean definition [Generic bean: class [org.springframework.integration.gateway.GatewayProxyFactoryBean]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] for bean 'processorStorageGateway': There is already [Generic bean: class [org.springframework.integration.gateway.GatewayProxyFactoryBean]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] bound.
2020-09-14 12:09:16.342 ERROR 3828 --- [  restartedMain] o.s.b.d.LoggingFailureAnalysisReporter   :

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

Description:

The bean 'processorStorageGateway', defined in null, 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

I have tried approach like using property in registry app's central-config folder, .yml file(which holdds central configuration for client app)

spring:
    
    main:
        allow-bean-definition-overriding: true

but of no luck yet. I have tried defining @Service annotation also on the Interface whose bean injection fails as per error above like below

@MessagingGateway
@Service
public interface ProcessorStorageGateway { 
..... }

I saw two reference class files which uses this interface to autowire FailJobscheduler and ExternalQueuelistener which are trying to inject this bean 'processorGateway' of type interface at runtime, renaming their autowiring property din't help resolve the issue also, like mentioned below

@Component
public class FailJobsScheduler {

    private final Logger log = LoggerFactory.getLogger(this.getClass());

    @Autowired
    private JobService jobService;

    @Autowired
    private ProcessorStorageGateway processorStorageGateway;
............
}

@Service
public class ExternalQueueListener {

    private final Logger log = LoggerFactory.getLogger(this.getClass());

    @Autowired
    private ProcessorStorageGateway processorStorageGateway;
.....
}

Currently stuck at this issue as Spring Boot-2.1 onwards default bean overriding not allowed at runtime. The above hit and trial mentioned at the begining also din't help . Can anybody help advise on this issue faced and best way to resolve it?

Answer 1

The above issue has been resolved by avoiding some duplicate Spring annotations, which were already present in project, during further investigation like @Configuration etc. and also in the main Spring-BOOT app class by mentioning the Component Scan to perform for the respective packages help resolved the issue