Ist es in Ordnung, Konfigurationsdateien in JARs zu speichern?

Es klingt nicht vernünftig für mich. Ich glaube, dass die Konfiguration einiger Anwendungen in JAR-Datei sein sollte. Dinge wie ORM-Mappings, Spring-Config, benutzerdefinierte Spring-Namespace XSD, andere XSDs, etc .. sollten in den meisten Fällen in Jar sein. Es ist ein wichtiger Teil des Deployment-Artefakts.

Die Tatsache, dass es nicht class file ist, bedeutet nicht, dass es aus jar entfernt werden sollte, nur weil es theoretisch geändert werden kann, ohne ein neues jar zu bauen. Kannst du dir eine Modifikation von * .hbm.xml in der Produktion vorstellen? für mich klingt es sehr gruselig .

Ich denke, einige Konfigurationen, wie Spring xml, sind in den meisten Fällen dazu gedacht, Ihre Anwendung und Abhängigkeiten besser zu organisieren, aber sie nicht zur Laufzeit in der Produktion zu ändern.

  

Es ist eine schlechte Form, irgendetwas zu haben   ist keine .class-Datei in ein JAR

gehen

Das ist Unsinn. Es ist in der Tat sehr gut Form, Ressourcen wie Symbole und andere Datendateien, die der Benutzer durch den Code verwendet, zusammen mit dem Code in die JAR zu legen. Dies ist, wofür die Methoden getResource() und getResourceAsStream() von Class und ClassLoader sind, und es macht viel robustere Anwendungen, als mit Ressourcenpfaden manuell herumzuspielen.

Konfigurationsdateien sind jedoch möglicherweise eine andere Sache. Wenn sie während oder nach der Bereitstellung geändert werden sollen, ist es relativ unpraktisch, sie in einer JAR-Datei zu speichern. Sie sollten in einem separaten Verzeichnis gespeichert werden.

Wenn Sie Änderungen in einer Konfigurationsdatei in einer JAR vornehmen (auch ohne eine Zeile Java-Code zu ändern), muss die gesamte JAR neu erstellt und erneut bereitgestellt werden. Klingt das vernünftig?

Es ist absolut in Ordnung, Nicht-Klassen-Dateien in eine JAR-Datei einzufügen, insbesondere Ressourcen, die die Anwendung benötigt (Bilder, lokalisierte Zeichenfolgen usw.). Sie müssen also entscheiden, welches Szenario zu Ihrer Situation passt:

• Wenn die Konfiguration festgelegt ist und sich nur ändern wird, wenn eine neue JAR-Datei bereitgestellt wird, legen Sie sie in das JAR.
• Wenn die Konfiguration entweder manuell oder von der Anwendung geändert werden muss, speichern Sie sie im Dateisystem.

Wenn Sie sich für Letzteres entscheiden, sollten Sie eine Standard -Konfiguration in die JAR-Datei aufnehmen, um den Fall zu behandeln, wenn die externe Konfigurationsdatei fehlt. Der Standard kann direkt aus dem JAR geladen oder in das Dateisystem kopiert werden, um die neue bearbeitbare Konfiguration zu werden.

Möchten oder erwarten Sie, dass sie ohne eine neue Version des Codes geändert werden? Dann müssen Sie sie extrahieren.

Wenn die Antwort auf die Frage in nicht Sie nicht extrahieren sollte, da es Unterstützung ermöglichen würde, um mit ihnen herumzuspielen, ohne den Freigabeprozess durchzugehen. (Natürlich ist dies auch möglich, wenn sie in der JAR sind, aber etwas weniger verlockend.)

Update: Da Sie jedoch mehrere Deployment-Rechner erwähnt haben, gibt es eine dritte Option: Sie können sie extrahieren und in einen allgemein zugänglichen Bereich auf einem Netzwerklaufwerk platzieren. Manuell editierbare Konfigurationsdateien, die auf mehreren Rechnern repliziert werden (aber identisch sein sollten), sind dafür bekannt, dass sie nicht mehr synchron sind.

ORM-Tools (wie Hibernate oder IBatis) sollten nach der Bereitstellung der Anwendung nicht wirklich geändert werden. Also, nein, ich würde sagen, dass es für diese Art von Dateien keinen Sinn ergibt.

Abhängig von Ihren Anforderungen können anwendungsweite Konfigurationsdateien außerhalb des Jar / War platziert werden, so dass sie geändert werden können, ohne das jar neu erstellen zu müssen. Denken Sie daran, dass das Ändern von Anwendungsparametern in der Produktion eine schlechte Übung ist. Änderungen sollten zuerst in einer Vorproduktionsumgebung getestet werden.