Va bene mettere i file di configurazione in JAR?

Question

Stiamo discutendo nel mio ufficio di ciò che può e non può andare in un file JAR. È stato suggerito che è una cattiva forma avere qualcosa che non è un file .class in un JAR. Al momento abbiamo alcune configurazioni XML per Ibatis/etc, alcuni file di proprietà .. il solito. Tuttavia, c'è una spinta per estrarre tutti questi file da JAR e inserirli nel file system locale di ogni macchina di distribuzione. Suona ragionevole?

Answer 1

Non mi sembra ragionevole. Credo che la configurazione di alcune applicazioni dovrebbe essere nel file jar. Cose come mappature ORM, spring config, namespace primaverili personalizzati XSD, altri XSD, ecc. Dovrebbero essere nella maggior parte dei casi in jar. È una parte importante degli artefatti di dispiegamento.

Il fatto, che non è il file class, non significa che dovrebbe essere estratto da jar solo perché è teoricamente possibile modificarlo senza creare un nuovo jar. Potete immaginare una modifica di * .hbm.xml in produzione? per me suona molto spaventoso.

Penso che alcune configurazioni, come spring xml, siano intese nella maggior parte dei casi per organizzare meglio l'applicazione e le dipendenze, ma non per cambiarle in fase di esecuzione in produzione.

Answer 2

Se si apportano modifiche in un file di configurazione all'interno di un JAR (anche senza modificare alcuna riga di codice Java), l'intero JAR deve essere ricostruito e ridistribuito. Suona ragionevole?

Answer 3

Volete o aspettatevi che vengano modificati senza una nuova versione del codice? Quindi è necessario estrarli.

Se la risposta alla domanda in nient'altro che non dovrebbe estrarli, in quanto consentirebbe al supporto di armeggiare con loro senza passare attraverso il processo di rilascio. (Naturalmente questo è possibile anche se sono nel barattolo, ma un po 'meno allettante.)

Aggiornamento: Ma dal momento che lei ha citato più macchine di distribuzione, c'è una terza opzione: estrarli e metterli in una zona comunemente accessibili su un disco di rete. I file di configurazione modificabili manualmente che sono replicati su più macchine (ma dovrebbero essere identici) sono famosi per non essere sincronizzati.

Answer 4

è cattiva forma di avere tutto ciò che non è un file .class andare in un JAR

Che è una sciocchezza. È in effetti molto buono modulo per mettere risorse come icone e altri file di dati che l'utente ha utilizzato dal codice nel JAR insieme al codice. Questo è quello che i metodi getResource() e Class e ClassLoader sono per, e rende le applicazioni molto più robuste rispetto a fare confusione con i percorsi delle risorse manualmente.

Tuttavia, i file di configurazione sono probabilmente diversi. Se sono destinati a essere modificati durante o dopo la distribuzione, quindi averli in un file JAR è piuttosto scomodo e preferirli averli in una directory separata.

Answer 5

Gli strumenti ORM (come Hibernate o IBatis) non dovrebbero essere modificati una volta distribuita l'applicazione. Quindi, no, direi che non ha senso per quel tipo di file.

A seconda delle esigenze, i file di configurazione a livello di applicazione possono essere posizionati all'esterno di Jar/War in modo che possano essere modificati senza dover ricostruire il jar. Tieni presente che modificare i parametri dell'applicazione in produzione è, imho, una cattiva pratica. Le modifiche dovrebbero essere testate prima in alcuni ambienti di pre-produzione.

Answer 6

E 'assolutamente OK per mettere i file non di classe in un file JAR, in particolare le risorse che le esigenze applicative (immagini, stringhe localizzate, etc.) Sapendo questo, è necessario decidere quale scenario si adatta alla situazione:

• Se la configurazione è fissa e cambierà solo quando viene distribuito un nuovo file JAR, inserirlo nel JAR.
• Se la configurazione deve essere modificata, manualmente o dall'applicazione, memorizzarla sul filesystem.

Se si sceglie quest'ultima, si noti che è buona pratica includere una configurazione di default nel file JAR per gestire il caso in cui il file di configurazione esterno mancante. Il valore predefinito può essere caricato direttamente dal JAR o copiato nel filesystem per diventare la nuova configurazione modificabile.