Czy złe jest umieszczanie plików właściwości/plików konfiguracyjnych w słoikach?

Question

Na przykład:

MyApp to aplikacja internetowa, która zawiera plik właściwości (server.properties), który opisuje dane konfiguracyjne (np. Nazwy serwerów) dla aplikacji. W fazie projektowania plik server.properties znajduje się we własnym folderze projektu IDE (logicznym miejscu dla niego).

Teraz należy wdrożyć MyApp. IDE czyni dość banalnym zbieranie plików klas, jak również pomocniczych plików konfiguracyjnych. Teraz po prostu upuszczamy słoik w odpowiednim pojemniku internetowym i odejdziemy ...

Tydzień później ... dane konfiguracji serwera, które MyApp wykorzystuje, muszą zostać zmienione. Co ma więcej sensu?

A. Zmodyfikuj plik server.properties z powrotem w środowisku IDE i wygeneruj zupełnie nowy plik JAR. Redeploy. (co oznacza odrzucenie aplikacji w celu prostej zmiany konfiguracji).

B. Pęknięcie otworzyć już wdrożony Jar i zmodyfikować plik server.properties? (może wymagać wywołania funkcji odświeżania w MyApp, jeśli serwer.properties jest buforowany ... ale nie powinien wymagać pełnego odrzucenia aplikacji.) Należy również pamiętać o modyfikacji źródła server.properties, aby przyszłe wdrożenia nie przywracały właściwości server.properties do starych nazw serwerów).

C. Najpierw należy uczynić plik server.properties zewnętrznym względem pliku JAR. Bardzo podobny do procesu B., przy mniejszej różnicy przechowywania danych config zewnętrznego do słoika (wprowadza różne ścieżki między rozwojem i produkcją wdraża)

D. Inne:

Dzięki!

Answer 1

pójdę z D.

spróbować załadować pliki właściwości z zewnątrz JAR następnie, jeśli to nie pomoże, należy załadować właściwości wbudowanych w słoiku.

Pozwala to wypchnąć konfigurację "gotową" z każdą kompilacją (redukuje również złożoność wdrożenia, jeśli tylko za pomocą jednego pliku), jednocześnie umożliwiając nadpisywanie konfiguracji w sposób możliwy i dość prosty.

Answer 2

To zależy. Jeśli plik właściwości zawiera dane, które mają zostać zmienione przez użytkownika aplikacji lub biblioteki, powinien on znajdować się na zewnątrz.

Jeśli zawiera statyczne dane, a pliki właściwości zostały utworzone tylko w celu uniknięcia kodowania wartości w kodzie źródłowym lub jeśli pliki są zlokalizowanymi łańcuchami, zostawię je w słoiku. Przynajmniej dlatego, że plik właściwości zachęca ludzi do zmiany wartości;)

Answer 3

Należy pamiętać, że w J2EE nie można zagwarantować dostępu do plików spoza środowiska J2EE (brak bezpośredniego dostępu do plików).

Należy użyć interfejsu JNDI, aby wskazać źródło danych zawierające dane lub plik właściwości w artefaktach wdrażania.

Usługa Websphere domyślnie nie zezwala na bezpośredni dostęp do plików.

Answer 4

Zadałem podobne pytanie. Nie doszliśmy jeszcze do tego. Ale szukamy zasobów URL. Gdzie plik własności jest odczytywany bezpośrednio z SVN. Nie trzeba aktualizować niczego poza plikiem właściwości.

Answer 5

Często jest to kryterium, według którego należy przeprowadzić migrację kodu NIEAKTUALIZOWANY od testu do produkcji. Oznacza to, że nie można edytować osadzonych plików konfiguracyjnych. Możesz także zakończyć sytuację, w której musisz zmienić wdrożoną konfigurację - która często jest bardzo uciążliwa. Dlatego pozostawiamy konfigurację poza słojami.

Dla aplikacji Java EE należy uwzględnić JNDI lub plik właściwości w ścieżce klasy.

Mam aplikację internetową, w której konfiguracja jest pobierana z aplikacji internetowej sąsiada, aby oddzielić te dwie. To okazało się znacznie łatwiejsze.

Answer 6

D.

Załaduj właściwości w słoiku. Następnie utwórz nowe właściwości, używając domyślnych właściwości słoików. Następnie załaduj z zewnątrz słoika. Pozwala to na wybór dostosowania właściwości.

Answer 7

Używam plików właściwości w aplikacjach webowych (WAR), ale głównie w przypadku wartości domyślnych i elementów, które są bardziej lub mniej niezmienne (ponieważ aplikacje internetowe nie powinny aktualizować swoich WAR, nawet jeśli mogą).

W przypadku takich rzeczy jak to, o czym mówisz, jednak używam JNDI. Możesz zdefiniować właściwości jako zasoby w pliku web.xml. W ten sposób, w najgorszym przypadku, aktualizujesz web.xml, a nie samą aplikację.

Dla niektórych serwerów istnieją sposoby na przesłonięcie tych wartości zasobów bez dotykania w ogóle WAR. Na przykład w Tomcat.

Zwykle wykonuję jedną WAR dla testu, Q/A i produkcji i przesłonię zasoby środowiskowe dokładnie tak, używając plików xml Context Tomcat. Uważam, że jest to o wiele lepsze niż konieczność tworzenia wielu WAR lub modyfikacji WARS, ponieważ testowana przeze mnie aplikacja jest prawie identyczna z aplikacją, która jest w produkcji.

Answer 8

Myślę, że odpowiedź zależy od tego, czy uważasz, że potrzebujesz kontroli wersji dla konfiguracji. (Mogą one być configs produkcyjne lub configs do testów regresji ...)

• Jeśli nie potrzebujemy kontroli wersji, a następnie opcja D z zewnętrznego pliku właściwości, który nadpisuje plik nieruchomość jest dobry. Opcje B i C są bardziej otwarte na przesadę, ale jeśli naprawdę zależy Ci na używaniu kontroli wersji :-)
• Jeśli potrzebujesz kontroli wersji, opcja A daje ci większą kontrolę, ale jeśli masz możliwość wiele wdrożeń może również chcieć/potrzebować do kontroli wersji konfiguracji dla każdego wdrożenia. Przykładem są osobne wdrożenia na platformy testowe i produkcyjne.

Oto, jak to robimy, używając modułów Maven i "Nakładek" pliku Maven WAR.

1. Mamy wiele modułów dla komponentów kodu Java. Są to moduły JAR.
2. Mamy moduł "podstawowy webapp" dla zawartości statycznej, stron JSP i danych konfiguracji podstawowej (okablowanie sprężyny, właściwości domyślne). Jest to moduł WAR, więc wynikiem budowania jest WAR, która zawiera powyższe + wszystkie pliki JAR.
3. Każda odrębna "konfiguracja witryny" to moduł WAR zawierający specyficzne dla witryny przesłonięcia dla właściwości, plików i zawartości przewodów. Nadpisanie jest opisane za pomocą mechanizmu "nakładki" Maven WAR i powoduje powstanie nowej WO z "bazowej" WOJNY i nadpisań.

Wszystko to jest zaznaczone w kontrolce wersji, a aby dokonać zmian w konfiguracji, należy wykonać kompilację Mavena i WAR.

Answer 9

Tworzę aplikacje J2EE przy użyciu Spring. Długo szukałem tego samego problemu, a następnie znalazłem rozwiązanie. Moim problemem było określenie właściwości bazy danych w pliku właściwości poza plikiem wojny, który wdrażam. Rozwiązanie znalazłem na to jest użycie PropertyPlaceholderConfigurer i określić właściwości location zlokalizować swoją lokalizację systemu jak ten,

To był dość prosty i to działało w porządku!

Answer 10

Opcja D. W różnych środowiskach może trzeba określić Aby określić właściwości środowiskowych, takich jak połączenia z bazą danych lub serwer proxy itp

Inne rzeczy warto zwrócić uwagę jest to, że w produkcji może chcesz szybko zmienić właściwość bez konieczności pakowania słoja lub zastępowania pliku właściwości w słoiku.

E.g. Serwer bazy danych jest przewracany i musisz wskazać inny serwer (jeśli nie korzystasz z systemu równoważenia obciążenia baz danych). Wszystko, co musisz zrobić, to zastąpić właściwości bazy danych i zrestartować. Oszczędzasz tam dużo czasu.

Answer 11

Jeśli używasz Spring, możesz użyć obiektu placeholder do wykonania pracy.

<!-- 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"/> 

Można określić zasób w systemie plików, a także na ścieżce klasy, Wiosna najpierw spróbować rozwiązać wszystkie właściwości z systemu plików, a następnie Przenieś się na ścieżce klasy. Określenie atrybutu "ignore-resource-not-found" jako "true" spowoduje, że Spring nie wyrzuci wyjątku, jeśli plik nie jest obecny w systemie plików i nie zezwoli mu na zamianę właściwości ze ścieżki classpath.

Użycie tej kombinacji umożliwia również podzielenie właściwości na dwa pliki, na przykład możesz nigdy nie chcieć określać haseł w pliku w ścieżce klas i oczekiwać, że będą one określone zewnętrznie w systemie plików. Wszelkie właściwości, których brakuje w systemie plików, zostaną usunięte ze ścieżki klasy.

W folderze zawierającym:

application.jar 
config.properties 

Powinieneś móc używać:

java -jar application.jar 

To config.properties przykładowe dla odniesienia:

# 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