Spring boot application.properties maven 多模块项目

Question

We are using spring boot in a multi-module project.

We have a Domain access module which has the common domain object classes, repositories, together with configuration for the datasource, JPA, Hibernate, etc. These are configured using a application.properties. We put all this configuration into the common module to save duplicating these common configurations in the higher level modules.

This all works fine when building the domain module, so the configurations are loaded correctly in the test units.

However the problems start when we try to use the domain module in the higher layer modules; they have their own application.properties which means Spring loads them and not the the Domain module application.properties, which this means the data source is not configured because only the higher module application.properties are loaded.

What we would like is both the domain module and higher level application properties to be loaded by Spring. But we can't see any easy way to do this.

I'm thinking this must be a common problem, and wonder if there any recommended solutions for this problem?

As we are using spring-boot the solution should ideally use annotations instead of applictionContext.xml.

Answer 1

Maybe you should only use application.properties in the top-level aggregator project?

You can always use @PropertySource in the child projects to configure them with a name that is specific to their use case.

Or you can use different names for each project and glue them together in the top-level project using spring.config.location (comma-separated).

Answer 2

I agree with @Dave Syer. The idea of splitting an application into multiple modules is that each of those is an independent unit, in this case a jar file. Theoretically you could split each of those jar files into their own source repositories, and then use them across multiple projects. Let's say you want to reuse these domain classes in both a web and batch application, if all the APPLICATION level configuration is stored within each of the individual modules, it severely reduces their reusability.

IMO only the aggregating module should contain all of the configuration necessary to run as an application, everything else is simply a dependency that can be remixed and reused as necessary.

Answer 3

Maybe another approach could be to define specific profiles for each module and use the application.properties file just to specify which profiles are active using the spring.profiles.include property.

domain-module
- application.properties
- application-domain.properties

app-module
- application.properties
- application-app.properties

and into the application.properties file of app-module

spring.profiles.include=domain,app

Answer 4

Another thing you can do (besides only using application.properties at the top-level as Dave Syer mentions) is to name the properties file of the domain module something like domainConfig.properties .

That way you avoid the name clash with application.properties .

domainConfig.properties would contain all the data needed for the domain module to be able to tested on it's own. The integration with the rest of the code can easily be done either using multiple @PropertySource (one for domainConfig.properties and one for application.properties ) or configuring a PropertySourcesPlaceholderConfigurer bean in your Java Config (check out this tutorial) that refers to all the needed property files

Answer 5

in spring-boot since 2.4 support spring.config.import

eg

application.name=myapp
spring.config.import=developer.properties

# import from other module
spring.config.import=classpath:application-common.properties

or with spring.config.activate.on-profile

spring.config.activate.on-profile=prod
spring.config.import=prod.properties

ref: https://spring.io/blog/2020/08/14/config-file-processing-in-spring-boot-2-4