Allow adding packages to entity scanning without disabling the default scanning

[odrotbohm]

I would like to provide a library that adds JPA entities to the persistence context bootstrapped. Ideally I would like to achieve that without the user having to explicitly configure @EntityScan to include the package of that library solely by registering some auto configuration.

I've tried both @EntityScan on a configuration class and a BeanDefinitionRegistryPostProcessor to trigger EntityScanPackages.register(…) but EntityScanner will only apply the autoconfiguration package as fallback if no entity package is configured at all.

I can see that the semantics of @EntityScan are supposed to stay unchanged. I'd be fine with a programmatic approach, so maybe an explicit method EntityScanPackage.registerAdditional(…) could populate an additional list that EntityScanner adds on top of the defaulted base list?

[wilkinsona]

See also #19024, #27549, and #28232.

@odrotbohm, does @AutoConfigurationPackage come close to what you want?

[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.

[odrotbohm]

It does indeed. At least until someone explicitly uses @EntityScan somewhere in their application configuration in which case the configuration would break. So some way of adding to the entity packages would still be appreciated. I think it'll also make the feature a bit more discoverable. The docs currently don't mention @ACP and the Javadoc of both annotations don't mention that fallback mechanism either, and the sole presence of @EntityScan makes it very likely that developers just try to use that if what they want to do is adding entities.

[wilkinsona]

Thanks, @odrotbohm. I'm a bit concerned that providing a mechanism that's always additive will surprise users as it's not very Boot-like to have something that can't be switched off or overridden.

The documentation (both reference and javadoc) for @AutoConfigurationPackage is definitely lacking at the moment. That's what #27549 will address. I wonder if that would be sufficient here? I would expect it to update the reference documentation and the javadoc for both @EntityScan and @AutoConfigurationPackage to make the purpose of the two more clear and to highlight that auto-configuration packages are the default packages used for entity scanning, with @EntityScan being used to take complete control and override those defaults.

[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.

[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.

[odrotbohm]

Apologies for the delayed response. I still wonder whether there's a middle ground here. My primary concern is that you cannot write robust autoconfiguration for a library that wouldn't break apart if the application starts using @EntityScan. In particular, it would be hard for users to identify the root cause of the problem they start seeing as the app would just fail, claiming that a type is not known as entity, not leaving a clue at what might have caused this. Even if you do, you now have to scatter your @EntityScan with library specific base packages, just because you might want to align to a slightly unusual package arrangement of your application.

In my particular case, there's no point in adding the JAR to the project unless you actually include those additional entity types because without them the functionality the JAR would like to provide doesn't work properly. Wouldn't it be okay to provide that way of unconditionally adding the type to the entities to bootstrap but then clearly advise autoconfiguration authors to potentially provide library specific means (e.g. a configuration property) to disable that particular aspect if it?

That said, I'd very much appreciate a strong hint in @EntityScan on that it will disable automatic entity registration by library autoconfiguration in case you decide to go with the documentation-only approach.

[wilkinsona]

In the short term, we're going to improve the documentation of @AutoConfigurationPackage and @EntityScan (#27549). We'll leave this issue open for consideration in the longer term. @odrotbohm, can you provide a bit more context about the nature of the entities in the library and try to give us a feel for how common you think it is for them to be shared between applications?

[Bwvolleyball]

We have a very simple use case where this exact feature would be quite handy. Right now, we have a custom health indicator that we share across several services, and one of the functions of our health indicator is to insert records of status into the database (via JPA Entities) - each service has it's own database, but this common table in each database.

Right now, we've got the code responsible for this health indicator in a common library, but every consuming service that uses this needs to ensure it also does an @EntityScan that includes these entities.

We'd like to convert this portion of our library into a proper autoconfigure library, but until the library can self declare/register those entities we can't really do that effectively.

[wilkinsona]

@Bwvolleyball Assuming that the consuming services do not use @EntityScan, you could use @AutoConfigurationPackage in your library to add to the packages that are scanned.