Problem z nadpisywaniem właściwości aplikacji w Spring-boot (profil) uruchomionej przy użyciu narzędzia PropertiesLauncher - SOLVED

Question

Mam trudności z zastąpieniem właściwości zadeklarowanej w pliku właściwości aplikacji dla konkretnego profilu w ścieżce klasy z inną wartością zadeklarowaną w przesłania plik w systemie plików.

Mam aplikacji automatycznego skonfigurowany Wiosna-boot (czyli używając @EnableAutoconfiguration), który ma wiele profili, które mogę uruchomić za pomocą PropertiesLauncher zamiast JarLauncher (powód, mających do czynienia z ograniczeniami wdrożeniowych - muszę wdrożyć w rozłożeniu . katalog zamiast archiwum w tylko do odczytu plików)

obrębie korzeni mojej aplikacji, mam pewne właściwości aplikacyjnych profil specyficzny, na przykład:

application-dev.properties 
application-qa.properties 
application-prd.properties 

I powiedzmy, przez wzgląd na argument, że application-dev.properties zawiera:

foo.bar=baz 
foo.baz=other 

w każdym środowisku, może być konieczne, aby zastąpić właściwość istniejący, a także dostarczyć nieobecny jeden (jak hasło produkcyjnej, na przykład) , a problem, który widzę, dotyczy nadpisujących właściwości już zadeklarowanych w pliku application-${profile}.properties w ścieżce klas. (Właściwości nie są obecne w pliku classpath Zaopatrywanie działa dobrze, to nie kwestia.)

Say mam złożyć an właściwości Zastępuje w miejscu systemu plików, takich jak:

/local/appname/dev/overrides/application.properties 

i chcę zastąpić właściwość, foo.bar, a także zadeklarować nową właściwość, foo.password.

Dlatego zawartość pliku zastąpienia są:

foo.bar=overridden-value 
foo.password=something 

Kiedy uruchomić aplikację, należy użyć wiersza poleceń coś takiego:

java -Dspring.config.location=file:/local/appname/dev/overrides/ 
    -Dspring.profiles.active=dev 
    org.springframework.boot.loader.PropertiesLauncher 
    --debug & 

Problem widzę, że chociaż foo.password, właściwość nie zadeklarowana w pliku application-dev.properties odebrany, zastąpienie foo.bar jest ignorowane - nadal widzę wartość, baz od application-dev.properties zamiast wartości, overridden-value z /local/appname/dev/overrides/application.properties.

Z opcją --debug włączona, widzę rejestrowanie ConfigFileApplicationListener że został załadowany plik zarówno przesłaniana (z systemu plików), a plik profilu specyficzne (od ścieżki klasy), w tej kolejności.

Kusiło mnie, być może, naiwne, że ponieważ plik przesłaniania jest wymieniony jako pierwszy, jest on najpierw ładowany, a następnie zastępowany przez "domyślny" plik specyficzny dla profilu ze ścieżki klas, który jest wymieniony później.Doceniam jednak, że kolejność umieszczania w dzienniku niekoniecznie koreluje z zachowaniem. Próbowałem zmienić kolejność ścieżek zadeklarowanych na właściwości spring.config.location, aby classpath: było wymienione przed , ale to nie pomogło i nie jestem przekonany, że tak by było, zważywszy, że dokumentacja wiosennego rozruchu jasno stwierdza, że ​​domyślne lokalizacje właściwości są zawsze wyszukiwane, nawet jeśli podasz wartość dla spring.config.location.

Dokumentacja Wiosna-boot jest bardzo specyficzny o kolejności, w której właściwości są rozwiązywane za pomocą sprężyny-boot wykonywalnego JAR, w malejąco kolejności:

1. argumenty wiersza poleceń.
2. Właściwości systemu Java (System.getProperties()).
3. Zmienne środowiskowe systemu operacyjnego. atrybuty
4. JNDI z java:comp/env
5. RandomValuePropertySource który ma tylko właściwości w random.*.
6. Właściwości aplikacji poza z zapakowanego słoika (application.properties, w tym YAML i warianty profili).
7. Właściwości aplikacji zapakowane wewnątrz Słoik (application.properties w tym YAML i warianty profili).
8. @PropertySource adnotacje na twoich klasach @Configuration.
9. Właściwości domyślne (określone za pomocą SpringApplication.setDefaultProperties).

Zanotuj linii 6 i 7 - właściwości poza ponad Właściwości wewnątrz swoją jar.

Co nie jest powiedziane, ile mogę zobaczyć, a które mogą być źródłem mojego zamieszania/emisji, jest to, co dzieje się, gdy jesteś nie użyciu JAR ale rozebranego katalog (i dlatego PropertiesLauncher .)

Jeśli zachowanie rozbitego katalogu było zgodne z tym, co podano dla pliku JAR, to można by oczekiwać, że wartości właściwości zadeklarowane w /local/appname/dev/overrides/application.properties zastąpią dowolną z tych samych nazw zadeklarowanych w classpath:application-dev.properties, ale to nie wydaje się, że tak jest.

zauważył również z dokumentacji Wiosna-boot (załącznik C.4 na PropertiesLauncher) jest wzmianka o własności loader.home, który jest opisany jako”... [The] file Lokalizacja dodatkowymi właściwościami, np /opt/app (domyślnie jest to ${user.dir}) ".

Więc spróbowałem użyć loader.home zamiast spring.config.location, ale bez skutku.

(Aktualizacja: Próbowałem też za pomocą loader.config.location i mam dwie notatki: wydaje się chcieć plik zamiast katalogu (tak jego zachowanie jest nie analogiczne spring.config.location), a kiedy zrobił dostawa Ścieżka pliku, a nie katalog nadrzędny, nadal nie pomogła.)

Czy ktoś może zauważyć, co robię źle, lub jakie błędne założenia robię?

Answer 1

Dzięki, Dave, Twoja sugestia była w 100% poprawna.

Gdybym zmienić nazwę pliku właściwości w /local/appname/dev/overrides do application-dev.properties następnie wartości właściwości z tego pliku zrobić zastąpić te w classpath:application-dev.properties.

byłem pewien miał próbował tej kombinacji wczoraj, ale myślę, że to, co musi być zatrzymany to działa kiedy byłem zabawy z określeniem spring.config.location i dostaje to źle, więc nie szukał pliku w override dobre miejsce.