Załóżmy, że przekonaliście mnie do Make not WAR, but JAR
Jak sobie wyobrazić użycie np połączeń bazodanowych JNDI, gdy nie istnieje takie coś jak Tomcat developerski ze swoimi katalogami, oraz tomcat produkcyjny ze swoimi, bo jest jeden.
Chodzi nie tylko o bazy, ale takie pierdoły jak string do konfiguracji developerskiej vs klientowskiej
Inaczej ujmując pytanie, to jest bardziej: JNDI w embedded Tomcat versus samodzielny kontener.
Nie bardzo rozumiem pytanie. Masz sobie obok jara application.properties z odpowiednimi wartościami i tyle. W samym projekcie w src/main/resources możesz mieć developerski application.properties, ale potem na serwerze testowym czy produkcyjnym obok jara masz application.properties z wartościami które mają być użyte i tyle.
Alternatywnie możesz mieć wiele takich properties i wybierać je przez springowy profil który będzie wybrany.
Możesz też to wszystko zrobić bez springowego profilu.
Ale potwierdzam: java potrafi czytać pliki properties, ewentualnie yaml czy cokolwiek.
jarekr000000 napisał(a):
Ale potwierdzam: java potrafi czytać pliki properties, ewentualnie yaml czy cokolwiek.
HOCON, TOML - teraz na to jest moda
jarekr000000 napisał(a):
Możesz też to wszystko zrobić bez springowego profilu.
Ale potwierdzam: java potrafi czytać pliki properties, ewentualnie yaml czy cokolwiek.
Ja ostatnio napisałem aplikacje (w Kotlinie) którą uruchamiam tak java -jar sciezka_pliku_1 scieżka_pliku_2. Ale ze mnie hardcore :D