Circular dependency between AttributeConverter and JPA

[TofanMihai]

Circular dependency between AttributeConverter and JPA

[wilkinsona]

We don't, as far as I can see and remember, do anything with AttributeConverters in Spring Boot so it's not clear to me why the cycle exists. If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

[quaff]

Why would you inject JPA repositories into AttributeConverter ? IMO AttributeConverter should be pure function.

[Jayanta0123]

@TofanMihai, there's a typo (impkementing -> implementing) in your first comment. Kindly check.

[TofanMihai]

Why would you inject JPA repositories into AttributeConverter ? IMO AttributeConverter should be pure function.

I honestly agree, but this is the way it has been implemented in the project I am currently working on.
Trying to extract the logic and transform the converter into a service would be too cumbersome as it is currently applied on numerous entities and would mean modifying hundred of methods, trying to apply the converter logic after each load and before each persist.

[TofanMihai]

We don't, as far as I can see and remember, do anything with AttributeConverters in Spring Boot so it's not clear to me why the cycle exists. If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Thank you for your interest!
I have created a small demo reproducing the issue and attached it to this reply.

circular_dependency_demo.zip

[wilkinsona]

Thanks for the sample.

The cycle exists because Hibernate looks up Converter implementations through its BeanContainer abstraction and Spring Framework's SpringBeanContainer implementation.

Upon migrating to Jakarta EE and upgrading to Spring 3.0+, we've noticed that the EntityManagerFactory defined in HibernateJpaConfiguration is causing a circular dependency issue with our converters.

This reads to me like things used to work for you before upgrading to Spring Boot 3.x. I've downgraded the sample to Spring Boot 2.7.x (changing it to use javax.persistence), and the same circular reference exists. I have to go back to 2.4.0 before the application starts successfully.

I believe the change in behaviour is a side-effect of #24249. Bootstrapping the entity manager on a separate thread works around the circular dependency. You can restore this behaviour by setting spring.data.jpa.repositories.bootstrap-mode=deferred. The Spring Boot 3.2.6-based application starts successfully with this property in place.

That said, I would encourage you to update your converter so that it's a pure function as @quaff suggests. If you must keep the cycle but don't want to change the bootstrap mode (which can have broader consequences), you could also use ObjectProvider<HumanRepository> to inject the dependency into your converter. You can use Framework's SingletonSupplier so that the lookup of the repository bean is still lazy but it only performed once:

@Converter
public class NameConverter implements AttributeConverter<String,String> {

    private final Supplier<HumanRepository> humanRepository;

    public NameConverter(ObjectProvider<HumanRepository> humanRepository) {
        this.humanRepository = SingletonSupplier.of(() -> humanRepository.getObject());
    }

    @Override
    public String convertToDatabaseColumn(String s) {
    	// Use the repository during conversion
    	humanRepository.get().count();
        return s + "_converted";
    }

    @Override
    public String convertToEntityAttribute(String s) {
    	// Use the repository during conversion
    	humanRepository.get().count();
        return s.replace("_converted","");
    }

}