È una cattiva pratica includere file di proprietà / configurazione all'interno dei vasetti?

StackOverflow https://stackoverflow.com/questions/1208848

Domanda

Ad esempio:

MyApp è un'app Web che contiene un file delle proprietà (server.properties) che descrive i dati di configurazione (ad esempio i nomi dei server) per l'app. Nella fase di sviluppo, server.properties si trova nella propria cartella del progetto IDE (un punto logico per esso).

Ora è il momento di distribuire MyApp. L'IDE rende abbastanza banale il jaring dei file di classe e dei file di configurazione di supporto. Ora lasciamo cadere il Jar nel contenitore web appropriato e andiamo via ....

Una settimana dopo ... il server configura i dati che MyApp utilizza deve cambiare. Che ha più senso?

A. Modifica il file server.properties nuovamente in IDE land e genera un file jar completamente nuovo. Ridistribuire. (il che significa far rimbalzare l'app per una semplice modifica della configurazione).

B. Aprire il vaso già distribuito e modificare il file server.properties? (potrebbe essere necessario chiamare una funzione di aggiornamento in MyApp se server.properties è memorizzato nella cache ... ma non dovrebbe richiedere un rimbalzo completo dell'app. Inoltre, è necessario ricordare di modificare anche server.properties di origine, quindi le distribuzioni future non ripristinano server.properties ai vecchi nomi dei server).

C. Rendi server.properties esterno al file jar in primo luogo. Molto simile al processo di B, con la piccola differenza di mantenere i dati di configurazione esterni al vaso (introduce percorsi diversi tra le distribuzioni di sviluppo e produzione)

D. Altro:

Grazie!

È stato utile?

Soluzione

Vorrei andare con D.

Prova a caricare i file delle proprietà dall'esterno del file .jar, quindi, in caso contrario, carica le proprietà integrate nel vaso.

Ciò ti consente di inviare un " già pronto " la configurazione con ogni build (riduce anche la complessità di una distribuzione, anche se di un solo file), rendendo al contempo possibili e ragionevolmente semplici configurazioni di sostituzione.

Altri suggerimenti

Se si utilizza Spring, è possibile utilizzare il segnaposto della proprietà per eseguire il lavoro. 

<!-- try and resolve the config from the filesystem first and then fallback to the classpath -->
<context:property-placeholder location="file:config.properties, classpath:config.properties"
                              ignore-resource-not-found="true"/>

Puoi specificare una risorsa sul filesystem e anche sul classpath, Spring proverà prima a risolvere tutte le proprietà dal filesystem e poi fallback nel classpath. Specificando " ignore-resource-not-found " attributo come " true " impedirà a Spring di generare un'eccezione se il file non è presente nel filesystem e consentirà invece di risolvere le proprietà dal percorso di classe.

L'uso di questa combinazione consente anche di dividere le proprietà su due file, ad esempio potresti non voler mai specificare le password nel file sul percorso di classe e aspettarti che vengano specificate esternamente sul filesystem. Qualsiasi proprietà mancante dal filesystem verrà risolta dal percorso di classe.

In una cartella contenente: 

application.jar
config.properties

Dovresti essere in grado di usare: 

java -jar application.jar

Questo è un esempio di config.properties per riferimento: 

# This file contains properties that are used to configure the application
database.url=127.0.0.1
database.port=3306
database.user=root
database.pass=p4ssw0rd

Dipende. Se il file delle proprietà contiene dati che devono essere modificati dall'utente dell'applicazione o della libreria, è necessario che risiedano all'esterno.

Se contiene dati statici e hai creato i file delle proprietà solo per evitare di codificare i valori nel codice sorgente o se i file sono stringhe localizzate, li lascerei nel vaso. Almeno perché un file delle proprietà invita le persone a modificare i valori;)

D.

Carica le proprietà nel vaso. Quindi creare una nuova proprietà usando le proprietà jar-ed come predefinite. Quindi caricare dall'esterno del vaso. Ciò consente di selezionare le personalizzazioni delle proprietà.

Ricorda che in J2EE NON puoi accedere ai file dall'ambiente J2EE (nessun accesso diretto ai file).

Dovresti usare JNDI per puntare a un'origine dati contenente i tuoi dati, o un file delle proprietà nei tuoi artefatti di distribuzione.

Websphere, ad esempio, non consente l'accesso diretto ai file per impostazione predefinita.

Opzione D. In ambienti diversi potrebbe essere necessario specificare il desiderio di specificare le proprietà ambientali come la connessione al database o al proxy ecc.

Un'altra cosa degna di nota è che in produzione potresti voler cambiare rapidamente una proprietà senza dover preimballare un vaso o sostituire il file delle proprietà nel vaso.

es. Il server database è caduto e è necessario puntare a un altro server (se non si utilizza un bilanciamento del carico dei database). Quindi è sufficiente sostituire le proprietà del database e riavviare. Risparmia molto tempo lì.

Spesso è un criterio per la migrazione del codice UNCHANGED dal test alla produzione. Ciò implica che non è possibile modificare i file di configurazione incorporati. Inoltre, potresti finire in una situazione in cui è necessario modificare una configurazione distribuita, che spesso è molto ingombrante. Quindi, lasciamo la configurazione fuori dai barattoli.

Per le applicazioni Java EE prendere in considerazione JNDI o un file di proprietà nel percorso di classe.

Ho un'applicazione web in cui la configurazione viene recuperata da un'applicazione web vicina semplicemente per separare i due. Ciò si è rivelato molto più semplice.

Uso i file delle proprietà nelle webapp (WAR), ma principalmente per valori predefiniti e cose che sono più o meno immutabili (poiché le webapp non dovrebbero aggiornare i loro WAR anche quando possono).

Per cose come quelle di cui stai parlando, tuttavia, utilizzo JNDI. È possibile definire le proprietà come risorse nel file web.xml. In questo modo, nella peggiore delle ipotesi, aggiorni web.xml e non l'app stessa.

Per alcuni server ci sono modi per sovrascrivere questi valori di risorse senza toccare affatto il WAR. Ad esempio, in Tomcat.

Normalmente faccio una GUERRA per test, Q / A e produzione e sovrascrivo esattamente le risorse sensibili all'ambiente, usando i file xml di contesto di Tomcat. Lo considero molto meglio che dover creare più WAR o modificare WAR, poiché l'app che sto testando è quasi identica a quella in produzione.

Penso che la risposta dipenda dal fatto che tu pensi di dover controllare la versione per le configurazioni. (Potrebbero essere configurazioni di configurazione o configurazioni per i test di regressione ...)

  • Se non è necessario il controllo della versione, l'opzione D con un file di proprietà esterno che sovrascrive un file di proprietà è buona. Le opzioni B e C sono più aperte ai riepiloghi, ma se ti interessasse davvero avresti usato il controllo della versione :-)
  • Se è necessario il controllo della versione, l'opzione A offre un maggiore controllo, ma se si ha la possibilità di più distribuzioni, potrebbe essere necessario / necessario controllare la versione delle configurazioni per ogni distribuzione. Un esempio è distribuzioni separate su piattaforme di test e produzione.

Ecco come lo facciamo utilizzando i moduli Maven e il file WAR Maven " overlays " ;.

  1. Abbiamo più moduli per i componenti del codice Java. Questi sono moduli JAR.
  2. Abbiamo " base webapp " modulo per contenuto statico, JSP e dati di configurazione di base (cablaggio a molla, proprietà predefinite). Questo è un modulo WAR, quindi il risultato della costruzione è un WAR che contiene i file JAR sopra + tutti.
  3. Ogni "configurazione del sito" distinta è un modulo WAR che contiene sostituzioni specifiche del sito per proprietà, file di cablaggio e contenuto. L'override è descritto usando la Maven WAR "overlay". meccanismo, e si traduce in un nuovo WAR assemblato dalla "base" WAR e le sostituzioni.

Tutto questo viene controllato nel controllo della versione ed è necessario eseguire una build Maven e una distribuzione WAR per apportare modifiche alla configurazione.

Ho fatto una domanda simile. Non abbiamo ancora capito tutto. Ma stiamo esaminando le risorse URL. Dove il file delle proprietà viene letto direttamente da SVN. Non è necessario aggiornare altro che il file delle proprietà.

Sviluppo applicazioni J2EE usando Spring. Stavo correndo lo stesso problema da molto tempo e poi ho trovato una soluzione.  Il mio problema era specificare le proprietà del database in un file delle proprietà al di fuori del file di guerra che ho distribuito. La soluzione che ho trovato è utilizzare PropertyPlaceholderConfigurer e specificare la proprietà location per individuare la posizione del sistema in questo modo,

    

Questo è stato abbastanza semplice e ha funzionato bene!

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top