Spring ORM SpringBeanContainer when trying to create a bean fails with not found bean definition, and fallbacks to default hibernate bean creation

[aurimasniekis]

Affected Version: 5.3.28

There seems to be an issue with Spring ORM SpringBeanContainer when Hibernate tries to create a bean using the SpringBeanContainer::createBean method:

SpringContainedBean<?> createBean(String name, Class<?> beanType, LifecycleOptions lifecycleOptions, BeanInstanceProducer fallbackProducer)

https://github.com/spring-projects/spring-framework/blob/main/spring-orm/src/main/java/org/springframework/orm/hibernate5/SpringBeanContainer.java#L183-L185

Upon the creation of a bean, the method this.beanFactory.applyBeanPropertyValues(bean, name); is called. This method internally attempts to merge the bean definition. However, the definition does not exist and cannot be created by the developer due to Hibernate appending a counter suffix to the bean name (e.g., org.example.types.CustomType0). This causes the entire process to fail with the error message "No bean named org.example.types.CustomType0," ultimately resorting to Hibernate's fallback method for bean creation. This negates the intended purpose of using the SpringBeanContainer for bean creation.

https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/factory/support/AbstractAutowireCapableBeanFactory.java#L403

A review of the code history suggests that this behavior has remained unchanged for quite some time. However, this approach appears to be flawed and may need to be reconsidered to ensure the proper functioning of the integration between Spring ORM and Hibernate when dealing with the creation of beans.

[quaff]

Why a counter suffix will be appended to class name? IMO it's a bug that hibernate team should fix.

[aurimasniekis]

Why a counter suffix will be appended to class name? IMO it's a bug that hibernate team should fix.

Because it's parameterized bean

[jhoeller]

We could try to remove the suffix before considering this as a Spring bean name, but I really wonder why we get that name with a suffix there to begin with. Even for a parametermized bean, Hibernate should expose the raw bean name somewhere as well.

Is there a reliable indication for the provided bean name to be parameterized, so that we could strip the suffix for our purposes, but only in that specific case? Is this actually what you'd expect SpringBeanContainer to do, nevertheless finding a bean definition with name org.example.types.CustomType?

[aurimasniekis]

I do not really think the issue is the suffix of the bean name. The issue is that the SpringBeanContainer creates a bean without any definition and then tries to merge the definition or etc, on nonexisting bean.

I have forked the SpringBeanContainer and replaced the createBean with way to create definition of bean and return it.

private SpringContainedBean<?> createBean(
        String name,
        Class<?> beanType,
        LifecycleOptions lifecycleOptions,
        BeanInstanceProducer fallbackProducer
) {
    try {
        if (lifecycleOptions.useJpaCompliantCreation()) {
            if (this.beanFactory instanceof BeanDefinitionRegistry bdr) {

                RootBeanDefinition beanDefinition = new RootBeanDefinition(beanType);

                bdr.registerBeanDefinition(name, beanDefinition);

                Object bean = this.beanFactory.getBean(name);

                return new SpringContainedBean<>(
                        bean,
                        beanInstance -> this.beanFactory.destroyBean(
                                name,
                                beanInstance
                        )
                );
            } else {
                throw new IllegalStateException(
                        "Cannot register bean definition with non-BeanDefinitionRegistry: "
                        + this.beanFactory);
            }
        } else {
            return new SpringContainedBean<>(this.beanFactory.getBean(
                    name,
                    beanType
            ));
        }
    } catch (BeansException ex) {

[aurimasniekis]

If we still going around the suffix stuff here is the logic which causes the suffix addition when using custom types.

https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/mapping/BasicValue.java#L806-L866

[jhoeller]

It's not the lack of a bean definition, it's actually the presence of a provided bean name to begin with. We usually get callbacks for the BeanContainer.getBean(Class ...) variant, not for the variant with a bean name plus a Class. If a bean name is provided, we expect a pre-existing bean definition to get values from.

So in your case, it looks like we should essentially ignore the provided bean name and rather delegate to the getBean(Class ...) variant where no bean definition is expected to exist? Which makes me wonder why we receive a provided bean name here but not in other cases?

I guess we could check for the existence of a corresponding bean definition of the provided name and otherwise simply ignore the name.

[aurimasniekis]

I see, this makes more sense right now, as far as I have done the research and some unrelated issues to the same code the suffix is appended because CustomType can be customized by parameters so that the same type would have multiple beans, not sure if that's the greatest way to do it.

[aurimasniekis]

I think from my understanding the getBean with name doesn't really expect to get an already present bean like it's implemented but just the same as without name, but just a new instance of that type bean with name?

[jhoeller]

Maybe that's why Hibernate provides a name there indeed, as a key for distinction between different bean instances. We can keep using the name as a key as we usually do there, but in the createBean(name, type) algorithm, we can seamlessly fall back to plain type-based creation if no bean definition of the given name exists. I'll implement it that way for 6.0.11 and 5.3.29.

[aurimasniekis]

Going through other BeanContainer implementations it looks like my understanding is correct, Hibernate uses named getBean method to just create a bean with a different name for multiple instances of the same type bean.

hibernate/hibernate-orm@5460acd

[jhoeller]

The CDI BeanContainer implementation translates a given bean name to the jakarta.inject.Named annotation but I suppose that's not enforced in CDI, also finding a regular bean of that type if no bean with the specific name is found. So on our side, checking for the existence of a bean definition with the provided bean name and ignoring the name if not found seems to match that. As long as we keep using the provided name as a key for the bean instance.

Thanks for all the digging here, that's very helpful!