With no explicit configuration at all, Boot will scan the package tree starting at the @EnableAutoConfiguration for JPA entities and register them automatically. @EntityScan can be used to provide Boot with a different root package to scan, but this disables the Boot auto-configuration scanning for entities.

When writing a starter that provides entities that should be included, there is currently no transparent way to register them with the persistence provider. Using @EntityScan on an auto-configuration class causes the default scan to back off, and @AutoConfigurationPackage does not register JPA entities (like it registers JPA and other Spring Data repositories).

Since JPA entities are part of the "Boot default auto-configure scan", using @AutoConfigurationPackage should cause the indicated package to be scanned for entities as well.

Comment From: wilkinsona

This should already happen. In the absence of any entity scan packages, JpaBaseConfiguration should scan every package registered with AutoConfigurationPackages:

https://github.com/spring-projects/spring-boot/blob/09f675806227befb29fa233450f1fad0a339747a/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/orm/jpa/JpaBaseConfiguration.java#L151-L157

It sounds like that's not working for you. If you'd like us to spend some more time investigating, please spend some time creating a minimal sample that demonstrates the behaviour that you have described and share it with us by zipping it up and attaching it to this issue.

Comment From: chrylis

I'll give it a try. The project in question is a test harness anyway, so I'm optimistic.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: vlad-ti

spring-entity-scan-issue.zip I can confirm what @chrylis initially described. If you have a module "bar", which uses auto-configuration for detection of entities, and you have an application/module "foo" which depends on the module "bar", but has an @EntityScan annotation, then the auto configuration of the module "bar" won't discover its required entities. To resolve that, other both modules/applications have to have @EntityScan annotation, or both of them have to use auto-configuration without setting @EntityScan manually. This is quiet weird behavior, if you want to develop a library (e.g. module "bar") which intends to initialize its entities.

The linked zip above contains an example spring boot application which exemplifies the described problem. Steps to reproduce the issue:

  • Start the project via "mvn spring-boot:run" from your command line
  • Open URL "localhost:8080/foo" in your browser: you get "[]" as response, as the FooEntity was initialized
  • Open URL "localhost:8080/bar" in your browser: you get internal server error. On command line you will see QuerySyntaxException: BarEntity is not mapped
  • If you adapt the code, either by adding @EntityScan to BarConfiguration, or by removing @EntityScan from FooApplication, then the error gets resolved

Comment From: wilkinsona

In a nutshell, the problem described above was the following:

Since JPA entities are part of the "Boot default auto-configure scan", using @AutoConfigurationPackage should cause the indicated package to be scanned for entities as well.

Your sample demonstrates, when you remove @EntityScan from FooApplication, that this already works as described. Removing @EntityScan allows the @AutoConfigurationPackage that's present on BarConfiguration via its @EnableAutoConfiguration annotation to add to the packages that are scanned.

The intention is that you use @AutoConfigurationPackage when you want to make additive contributions to the packages that are scanned. This works well in a library module that wants to make additions to an application. Then, in the application itself, you can then allow any modules to contribute via their use of @AutoConfigurationPackage or you can use @EntityScan to take control over exactly which packages are scanned. If @EntityScan was additive, as I think you're suggesting, the ability to take control would be lost.

Comment From: vlad-ti

I understand, that the ability of taking control for loading of all entities via @EntityScan might be sometimes demanded as well. However, then it gets tricky for those modules/applications which desire to rely on @AutoConfigurationPackage for entity scanning. If you have an application "foo" which relies on auto configuration, and some other modules, on which the "foo" depends, then if at least one of these modules (like a third-party library "bar") declares @EntityScan, then the whole application including needs to start using @EntityScan for its entities, as well as for all dependent modules which rely on auto-configuration.

Comment From: wilkinsona

A library that intends to contribute additional entities to an application shouldn't be using @EntityScan. If it does, then that's a bug in the library that should be fixed.