Custom base repository not considered for query method discovery when provided through a repository factory only

[xiaobin8811]

Summary

When defining a custom base repository interface plus implementation, Spring Data JPA attempts to derive a query from a non-derived method name and fails with:

No property 'getObj' found for type 'User'

Environment

• Spring Boot: 4.0.0
• Java: 25
• OS: macOS

Code Snippet

@SpringBootApplication
@EnableJpaRepositories(
    basePackages = "com.example.demo.dao",
    repositoryFactoryBeanClass = CustomBaseRepositoryFactoryBean.class
)
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

@NoRepositoryBean
public interface BaseDao<T, ID extends Serializable>
        extends JpaRepository<T, ID>, JpaSpecificationExecutor<T> {
    T getObj(ID id);
}

public class BaseDaoImpl<T, ID extends Serializable>
        extends SimpleJpaRepository<T, ID>
        implements BaseDao<T, ID> {

    private final EntityManager entityManager;

    public BaseDaoImpl(JpaEntityInformation<T, ?> entityInformation,
                       EntityManager entityManager) {
        super(entityInformation, entityManager);
        this.entityManager = entityManager;
    }

    @Override
    public T getObj(ID id) {
        return findById(id).orElse(null);
    }
}

User repository:

public interface UserDao extends BaseDao<User, Long> {}

Observed Behavior

Application fails to start with:

org.springframework.beans.factory.UnsatisfiedDependencyException: ...
No property 'getObj' found for type 'User'

[mp911de]

Please include the full stack trace in the report, alternatively, if you would like us to spend some time helping you to diagnose the problem, please provider a minimal yet complete 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.

[dodgex]

Hey @mp911de we faced the same issue. While we also have a custom repositoryFactoryBeanClass = CustomBaseRepositoryFactoryBean.class the issue even occurs when only having BaseDao / BaseDaoImpl classes in use.

I created a small repro project from the example code above. Testing should be as easy as running mvnw spring-boot:run.

issue-4093.zip

[dodgex]

I managed to create a (hopefully) minimal example with repositoryFactoryBeanClass too.

Here the error is pretty much the same, but I guess it might help to have both cases to test.

You can run this with mvnw spring-boot:run too

issue-4093-2.zip

Caused by: org.springframework.data.core.PropertyReferenceException: No property 'refresh' found for type 'User'

[mp911de]

You need to declare the repositoryBaseClass explicitly, for example:

@EnableJpaRepositories(
        basePackageClasses = UserDao.class,
        repositoryFactoryBeanClass = CustomRepositoryFactoryBean.class,
        repositoryBaseClass = CustomRepositoryImpl.class
)

Spring Data’s configuration infrastructure passes annotation attributes through to the corresponding repository FactoryBean instances. A custom RepositoryFactory created within createRepositoryFactory(…) is not taken into account for metadata derivation. Given the code you shared (even though your factory requires an ApplicationEventPublisher), the arrangement can be simplified to:

@EnableJpaRepositories(
        basePackageClasses = UserDao.class,
        repositoryBaseClass = CustomRepositoryImpl.class
)

Generally, it is worth revisiting the use of …Aware callbacks in RepositoryFactoryBeanSupport. A more consistent callback model could help cover additional edge cases, allowing RepositoryFactory subclasses such as yours to avoid custom constructor arguments and thereby reduce complexity for common customization scenarios.

[dodgex]

Thank you for your response, is it some new requirement to declare repositoryBaseClass?

The current code works fine in our Spring Boot 2.7 (dont ask :D) and 3.5 applications.

The Problem is, that our real CustomRepositoryFactory can switch between two implementatins (repositoryBaseClasses) based on the interface used (one with and one withoud firing events when saving etc).

	@Override
	protected SimpleJpaRepository<?, ?> getTargetRepository(
			RepositoryInformation information, EntityManager entityManager) {
		JpaEntityInformation<?, Serializable> entityInformation =
				getEntityInformation(information.getDomainType());
		if (isEventCrudRepository(information.getRepositoryInterface())) {
			return new EventCustomRepositoryImpl(entityInformation, entityManager,
				applicationEventPublisher);
		}
		return new CustomRepositoryImpl(entityInformation, entityManager);
	}

[mp911de]

Beginning with the 4.0 generation, we introduced enhanced introspection of repository structure. The framework now analyzes the structural elements that make up a repository, its classes, interfaces, and composed fragments, to identify query methods, base-class methods, and related characteristics without creating the underlying repository factory. This capability was introduced as part of our ahead-of-time efforts, where determining the repository base class should not require creating the full factory.

Motivated by your ticket, I've fixed spring-projects/spring-data-commons#3423 to avoid property overriding of the repositoryBaseClass for a repository factory bean.

Without the fix above, if you require additional flexibility to dynamically provide the base class consider a BeanPostProcessor that sets the repositoryBaseClass on RepositoryFactoryBeanSupport instances according to your requirements, for example:

@Configuration
class MyConfiguration {

    @Bean
    static BeanPostProcessor exposeMethodMetadata() {

        return new BeanPostProcessor() {

            @Override
            public Object postProcessBeforeInitialization(Object bean, String beanName) {

                if(bean instanceof RepositoryFactoryBeanSupport<?,?,?> factoryBean) {
                    // factoryBean.getObjectType() returns the repository interface
                }
                return bean;
            }
        };
    }
}

Once you have access to the new version you should be able to simplify those changes to overriding the getRepositoryBaseClass(…) method in the repository factory and returning the base class (for introspection purposes). You will have to keep your repository factory though as the built-in variant doesn't support injection of additional dependencies into the base repository instance.

[dodgex]

Thanks a lot. :)

I was able to add a BeanPostProcessor with your example, that was able to handle both Repository Implementations we have.