sostituzione di proprietà primaverili per test e produzione

Mi sono imbattuto in questo per la sostituzione della proprietà in spring

 

ma sfortunatamente, non vogliamo questo nel file xml perché vogliamo riutilizzare il file nei nostri test ma scambiare il file test.properties per il test. vale a dire. vogliamo testare tutti i binding di produzione ma con proprietà che sono adatte per test come localhost, per esempio. Come possiamo caricare ApplicationContext ma con file di proprietà differenti?

grazie, Dean

Metti la configurazione del segnaposto di proprietà in un file di configurazione xml extra di spring.

Per esempio:

  • applicationContext.xml – per la normale configrazione senza alcuna configurazione segnaposto di proprietà
  • applicationContext-config.xml – contiene solo un segnaposto di proprietà che carica il file di configurazione di produzione.
  • testApplicationContext.xml . Questo file include s applicationContext.xml e utilizza un segnaposto di proprietà con un altro file di proprietà.

In un’applicazione Web è ansible caricare tutti i file di contesto di produzione con questo modello di applicationContext*.xml .

Per i test è necessario caricare solo testApplicationContext.xml questo includerà la normale configurazione, ma con altre proprietà.

diversi approcci:


1. Proprietà ‘Ordine’

in src/main/resources/your-conf.xml

  

in src/test/resources/your-test-config.xml

  

Se si esegue il test con src/test/resources come percorso di class di test, quanto sopra garantirà l’override di src/main/resources/esb-project-config.properties con src/test/resources/esb-project-config.properties .

Ciò sostituirà comunque l’intero property-placeholder , pertanto è necessario fornire tutte le proprietà necessarie nella propria applicazione per questo property-placeholder test. per esempio

  

2. PropertyOverrideConfigurer

   

per sovrascrivere determinate proprietà individuali . Alcuni esempi qui


3. Variabili di sistema

È ansible utilizzare un prefisso per controllare le proprietà specifiche dell’ambiente, questo può essere fatto utilizzando le variabili di sistema:

   

In questo caso vedrà sempre sotto:

   

per impostazione predefinita , a meno che non sia impostata una variabile di sistema ENV_SYSTEM . Se è impostato su qa , ad esempio, verrà automaticamente visualizzato sotto:

   

4. Profili a molla

Un altro approccio consiste nel rendere specifico il profilo dei bean. Per esempio:

       

L’ esb-project-config appropriato verrà caricato in base a un set di profili. Ad esempio, caricherà esb-project-config.dev.properties :

 GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); ctx.getEnvironment().setActiveProfiles( "dev" ); ctx.load( "classpath:/org/boom/bang/config/xml/*-config.xml" ); ctx.refresh(); 

  • NOTA: gli approcci “Variabili di sistema” e “Profili di sistema” vengono solitamente utilizzati per passare da ambienti diversi anziché solo “dev <==> test” in modalità dev, ma sono comunque utili funzionalità da tenere presente.
  • Sul tag di contesto è ansible indicare che se un file di proprietà non esiste non è necessario che fallisca.
  • I file delle proprietà vengono caricati nell’ordine in cui vengono dichiarati. (Potrebbe anche essere una proprietà da dichiarare sul tag. Non sono sicuro)
  • Se una proprietà viene dichiarata più volte, viene utilizzato l’ultimo valore caricato.

Utilizziamo queste tre funzionalità come segue:

Dichiariamo due file di proprietà:

 classpath:esb-project-config.properties, classpath:esb-project-config-override.properties 

Il primo file di proprietà contiene impostazioni predefinite e configurazione di sviluppo sensate. Questo file è parte della tua applicazione.

Il secondo file di proprietà è un file disponibile sul percorso di class di test o anche sul percorso di class di produzione del server di applicazioni. Questo file è esterno all’applicazione In questo modo possiamo sovrascrivere le proprietà per ogni ambiente e avere solo una versione della nostra applicazione.

Quindi ecco l’esempio delle proprietà che usiamo:

   

Il mio metodo preferito, come aggiunto dalla spring 3.1, è il seguente:

Nel tuo * -context.xml:

  

e in web.xml:

  spring.profiles.default prod  

È quindi ansible specificare l’ambiente in fase di esecuzione, ad esempio:

 mvn -Dspring.profiles.active=dev jetty:run 

O comunque tu passi argomenti al tuo contenitore.

Sembra:

        

Non funziona. Ma puoi fare: