To Twój wybór. Istnieją zasadniczo trzy sposoby w archiwum aplikacji Java (WAR):
1. Umieść go w ścieżce klas
Abyś mógł załadować go ClassLoader#getResourceAsStream()ścieżką względną do ścieżki klas:
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("foo.properties");
// ...
Properties properties = new Properties();
properties.load(input);
Tu foo.propertiesma być umieszczony w jednym z korzeni, które są objęte domyślnej ścieżki klasy webapp, np webapp użytkownika /WEB-INF/libi /WEB-INF/classes, serwera /liblub JDK / JRE użytkownika /lib. Jeśli plik właściwości jest specyficzny dla aplikacji internetowej, najlepiej jest go umieścić /WEB-INF/classes. Jeśli opracowujesz standardowy projekt WAR w IDE, upuść go w srcfolderze (folder źródłowy projektu). Jeśli korzystasz z projektu Maven, upuść go w /main/resourcesfolderze.
Możesz również umieścić go gdzieś poza domyślną ścieżką klasy i dodać jej ścieżkę do ścieżki klasy apserver. Na przykład w Tomcat możesz go skonfigurować jako shared.loaderwłaściwość Tomcat/conf/catalina.properties.
Jeśli umieściłeś foo.propertiesgo w podobnej strukturze pakietu Java com.example, musisz go załadować jak poniżej
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("com/example/foo.properties");
// ...
Zauważ, że ta ścieżka modułu ładującego klasy kontekstu nie powinna zaczynać się od /. Tylko wtedy, gdy używasz „względnego” modułu ładującego, takiego jak SomeClass.class.getClassLoader(), wtedy rzeczywiście musisz go uruchomić za pomocą /.
ClassLoader classLoader = getClass().getClassLoader();
InputStream input = classLoader.getResourceAsStream("/com/example/foo.properties");
// ...
Widoczność pliku właściwości zależy jednak od danego modułu ładującego klasy. Jest widoczny tylko dla tego samego modułu ładującego klasę, który załadował klasę. Jeśli więc klasa jest ładowana przez np. Wspólny moduł ładujący klasy serwera zamiast modułu ładującego klasy aplikacji sieci Web, a plik właściwości znajduje się w samej aplikacji sieci web, wówczas jest niewidoczny. Moduł ładujący klasy kontekstu jest najbezpieczniejszym wyborem, więc możesz umieścić plik właściwości „wszędzie” w ścieżce klasy i / lub zamierzasz mieć możliwość zastąpienia pliku dostarczonego przez serwer z aplikacji internetowej.
2. Umieść w treści WWW
Aby można go było załadować za ServletContext#getResourceAsStream()pomocą ścieżki względnej dla treści WWW:
InputStream input = getServletContext().getResourceAsStream("/WEB-INF/foo.properties");
// ...
Zauważ, że zademonstrowałem, aby umieścić plik w /WEB-INFfolderze, w przeciwnym razie byłby publicznie dostępny dla każdego przeglądarki. Zauważ też, że ServletContextjest w dowolnej HttpServletklasie, dostępny tylko dla dziedziczonych GenericServlet#getServletContext()i Filterprzez FilterConfig#getServletContext(). W przypadku, gdy nie jesteś w klasie serwletów, zwykle można to zrobić przez wstrzyknięcie @Inject.
3. Umieść go w lokalnym systemie plików dysku
Abyś mógł załadować go w zwykły java.iosposób z absolutną ścieżką lokalnego systemu plików na dysku:
InputStream input = new FileInputStream("/absolute/path/to/foo.properties");
// ...
Zwróć uwagę na znaczenie korzystania ze ścieżki bezwzględnej. Względne ścieżki lokalnego systemu plików dysku są absolutnie nie do przyjęcia w aplikacji internetowej Java EE. Zobacz także pierwszy link „Zobacz także” poniżej.
Który wybrać?
Po prostu rozważ zalety / wady według własnego uznania w zakresie konserwacji.
Jeśli pliki właściwości są „statyczne” i nigdy nie muszą się zmieniać w czasie działania, możesz zatrzymać je w WAR.
Jeśli wolisz móc edytować pliki właściwości spoza aplikacji internetowej bez potrzeby przebudowywania i ponownego wdrażania WAR za każdym razem, umieść go w ścieżce klasy poza projektem (w razie potrzeby dodaj katalog do ścieżki klasy).
Jeśli wolisz programowo edytować pliki właściwości z poziomu aplikacji internetowej za pomocą Properties#store()metody, umieść ją poza aplikacją internetową. Ponieważ Properties#store()wymaga to Writer, nie można poruszać się po ścieżce systemu plików dysku. Ścieżkę tę można z kolei przekazać do aplikacji sieci Web jako argument maszyny wirtualnej lub właściwość systemową. Ze względów bezpieczeństwa nigdy nie używajgetRealPath() . Wszystkie zmiany w folderze wdrażania zostaną utracone podczas ponownego wdrażania z tego prostego powodu, że zmiany nie są odzwierciedlone w oryginalnym pliku WAR.
Zobacz też: