Hello, until 6.1.7 my program had been working fine for many years, but 6.2.0 introduced a change that made it break with:

"Could not register object [presetClientService@5404b7d9] under bean name 'blabla': there is already object [presetClientService@5404b7d9] bound"

The hash Id is the same so I'm under the impression that some bean is found in the bean registry and spring tries to re-add it in the registry. Why ?! I was not able to create a simple reproducer yet. To give you more details the code looks like this with 3 @Configuration classes referenced:

AnnotationConfigApplicationContext sphereContext = new AnnotationConfigApplicationContext(MainSphereSpringContext.class);
AnnotationConfigApplicationContext moduleContext = new AnnotationConfigApplicationContext();
moduleContext.register(ModuleSpringConfig.class, OleaDockingSpringConfig.class);
moduleContext.setParent(sphereContext);
moduleContext.refresh();

And the failing @Configuration class contains:

@Bean
public PresetClientService presetClientService() {
    return new PresetClientService(someService());
}

@Bean
public ModuleConfigPresenterImpl configPresenter() {
    return new ModuleConfigPresenterImpl(segmentActionDirectory(), presetClientService());
}

The problem comes from the call to presetClientService(). If I replace this call with null, the loading of the context is OK. Was working fine since years and broke with 6.2.0. I could re-try to create a real-failing sample if really needed, but for now I failed at it. Regards

Comment From: bclozel

We are going to need that sample unfortunately. I'm not sure we have enough information to understand where the problem is.

Comment From: jhoeller

Also, please try to reproduce this against 6.2.3 rather than 6.2.0. Several regressions have been fixed in the meantime which makes it easier to isolate where a remaining problem could be.

Comment From: fmarot

Sorry, I should have mentioned I also tested against the latest 6.2.3 and 7.0.0-M2 but they also have the same problem.

Comment From: jhoeller

@fmarot for a start, it would help to see the stacktrace for that exception. That's essentially an assertion, for some reason addSingleton seems to be called twice for the same bean instance in your scenario.

Comment From: fmarot

Here is the stacktrace. I'll try to write a SSCCE (https://sscce.org/) but no guarantee.

java.lang.IllegalStateException: Could not register object [com.oleamedical.module.viewing.PresetClientServiceImpl@285489cc] under bean name 'presetClientService': there is already object [com.oleamedical.module.viewing.PresetClientServiceImpl@285489cc] bound
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.addSingleton(DefaultSingletonBeanRegistry.java:155)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:372)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:337)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.instantiateSingleton(DefaultListableBeanFactory.java:1155)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingleton(DefaultListableBeanFactory.java:1121)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:1056)
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:987)
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:627)
    at com.oleamedical.module.application.AbstractSeriesViewerModuleApp.createSpringContext(AbstractSeriesViewerModuleApp.java:480)
    at com.oleamedical.module.application.AbstractSeriesViewerModuleApp.newDocumentRunnable(AbstractSeriesViewerModuleApp.java:704)

Comment From: jhoeller

Interesting, that's for a top-level bean even - no nesting, no circle. Somehow we seem to end up in a pre-registered state in that regular code path, that's clearly a bug.

That helps a lot for investigating this, thanks! I'll try to sort it out for the 6.2.4 release this Thursday which we'll do just-in-time for the Spring Boot 3.4.3 release.