It does not seem to be possible in inject a multi-valued property into the @EntityScan annotation.
Examples that do not work:
application.properties
packages-to-scan=package1,package2
@EntityScan(basePackages = "${packages-to-scan}")
@EntityScan(basePackages = "#{'${packages-to-scan}'.split(',')}")
---
application.yml
packages-to-scan:
- package1
- package2
@EntityScan(basePackages = "${packages-to-scan}")
@EntityScan(basePackages = "#{'${packages-to-scan}'}")
@EntityScan(basePackages = "#{${packages-to-scan}.join(',')}")
Related unresolved question on Stack Overflow: https://stackoverflow.com/questions/55374224/reading-multiple-entity-scan-packages-in-spring-boot-application
Comment From: wilkinsona
@EntityScan does not support property resolution so the behaviour you have seen is expected. Having external control over the entities that are scanned is a rare use case so it isn't directly supported. Without knowing why you want to change the packages that are scanned via configuration, it's hard to advise on an alternative. You may be able to use a number of profile-specific classes each annotated with @EntityScan so that the packages can be controlled based on the active profile.
To avoid duplication of effort, I'm going to close this issue in favour of the question on Stack Overflow.
Edit: I see now that the Stack Overflow question is a couple of years old. If the answers to the question and the above do not help you, please ask a question of your own that explains why you want to externalize the packages to scan. That will make it easier for people to suggest an appropriate alternative.
Comment From: wilkinsona
I was mistaken above. As shown by https://github.com/spring-projects/spring-boot/issues/25436, @EntityScan did support property resolution in 2.3 so, if we decide to reinstate support, we might want to consider how to handle multi-value properties.
Comment From: reckart
It would be great if the same solution could be applied also to other annotations related to package scanning such as @AutoConfigurationPackage and @ComponentScan.
Comment From: mbhave
@reckart As Andy mentioned, could you elaborate on why you want to change the packages based on configuration?
Comment From: reckart
I am maintaining an application where we normally restrict the package scanning to packages that we ship. However, as part of allowing users to supply plugins, I thought it would be useful if the users could re-configure the package scanning to allow the packages from their plugins to be scanned as well. Mind, a better plugin mechanism might also resolve that - but for a poor-mans plugin approach where people can simply throw in a few new JARs without having to recompile the entire thing, it would come in quite handy if they could extend the package scanning scope without having to recompile the main application.
Comment From: mbhave
Thanks for the context.
It looks like @ComponentScan supports placeholder resolution with comma-separated values.
I think in that case it would make sense to reinstate the behavior in #25436 so that it aligns with component scanning and also handle multiple values.
Comment From: mbhave
Closing in favor of PR #27355.