Spring boot application.properties progetti multi-modulo maven

Question

Stiamo usando il boot a molla in un progetto multi-modulo.

Abbiamo un modulo di accesso al dominio che include le classi di oggetti dominio comuni, i repository, insieme alla configurazione per l'origine dati, JPA, Hibernate, ecc. Questi sono configurati utilizzando un'applicazione.properties. Abbiamo inserito tutta questa configurazione nel modulo comune per risparmiare la duplicazione di queste configurazioni comuni nei moduli di livello superiore.

Questo funziona correttamente quando si crea il modulo di dominio, quindi le configurazioni vengono caricate correttamente nelle unità di test.

Tuttavia i problemi iniziano quando proviamo ad usare il modulo di dominio nei moduli di livello superiore; hanno le loro proprie proprietà application.properties, il che significa che Spring li carica e non il modulo Domain application.properties, il che significa che l'origine dati non è configurata perché sono caricati solo i moduli superiori application.properties.

Quello che vorremmo è sia il modulo dominio che le proprietà dell'applicazione di livello superiore da caricare da Spring. Ma non possiamo vedere un modo semplice per farlo.

Sto pensando che questo deve essere un problema comune e mi chiedo se esistono soluzioni consigliate per questo problema?

Poiché stiamo utilizzando il boot di primavera, la soluzione dovrebbe idealmente utilizzare le annotazioni anziché applictionContext.xml.

Answer 1

Forse dovresti usare solo application.properties nel progetto di aggregatore di primo livello?

È sempre possibile utilizzare @PropertySource nei progetti figlio per configurarli con un nome specifico per il loro caso d'uso.

Oppure è possibile utilizzare nomi diversi per ciascun progetto e incollarli insieme nel progetto di livello superiore utilizzando spring.config.location (separati da virgola).

Answer 2

Un'altra cosa che si può fare (oltre a usare solo application.properties al livello principale come menziona Dave Syer) è denominare il file delle proprietà del modulo dominio come domainConfig.properties.

In questo modo si evita il nome scontro con application.properties.

domainConfig.properties conterrà tutti i dati necessari affinché il modulo di dominio possa essere testato su di esso. L'integrazione con il resto del codice può essere fatto facilmente sia usando multipla @PropertySource (uno per domainConfig.properties e uno per application.properties) o la configurazione di un PropertySourcesPlaceholderConfigurer fagiolo nel tuo Java Config (check out this tutorial) che si riferisce a tutti i file di proprietà necessari

Answer 3

Sono d'accordo con @Dave Syer. L'idea di dividere un'applicazione in più moduli è che ognuno di questi è un'unità indipendente, in questo caso un file jar. In teoria è possibile suddividere ciascuno di questi file jar nei propri repository di origine e quindi utilizzarli in più progetti. Supponiamo che tu voglia riutilizzare queste classi di dominio in un'applicazione web e batch, se tutta la configurazione del livello APPLICATION è memorizzata all'interno di ciascuno dei singoli moduli, riduce gravemente la loro riusabilità.

IMO solo il modulo di aggregazione deve contenere tutta la configurazione necessaria per l'esecuzione come applicazione, tutto il resto è semplicemente una dipendenza che può essere remixata e riutilizzata secondo necessità.

Answer 4

Forse un altro approccio potrebbe essere quello di definire profili specifici per ciascun modulo e utilizzare il file application.properties solo per specificare che i profili di streghe sono attivi utilizzando la proprietà spring.profiles.include.

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

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

e nel file application.properties di app-modulo

spring.profiles.include=domain,app