C'est ton choix. Il existe essentiellement trois méthodes dans une archive d'application Web Java (WAR):
1. Mettez-le dans classpath
Pour que vous puissiez le charger ClassLoader#getResourceAsStream()avec un chemin relatif au chemin de classe:
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("foo.properties");
// ...
Properties properties = new Properties();
properties.load(input);
Ici, foo.propertiesest censé être placé dans l'une des racines qui sont couvertes par le chemin de classe par défaut d'une webapp, par exemple les webapp /WEB-INF/libet les /WEB-INF/classesserveurs /libou les JDK / JRE /lib. Si le fichier de propriétés est spécifique à une application Web, le mieux est de le placer /WEB-INF/classes. Si vous développez un projet WAR standard dans un IDE, déposez-le dans le srcdossier (dossier source du projet). Si vous utilisez un projet Maven, déposez-le dans le /main/resourcesdossier.
Vous pouvez également le placer quelque part en dehors du chemin de classe par défaut et ajouter son chemin au chemin de classe du serveur d'applications. Dans Tomcat par exemple, vous pouvez le configurer comme shared.loaderpropriété de Tomcat/conf/catalina.properties.
Si vous l'avez placé foo.propertiesdans une structure de package Java comme com.example, vous devez le charger comme ci-dessous
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("com/example/foo.properties");
// ...
Notez que ce chemin d'un chargeur de classe de contexte ne doit pas commencer par un /. Ce n'est que lorsque vous utilisez un chargeur de classe "relatif" tel que SomeClass.class.getClassLoader(), que vous devez en effet le démarrer avec a /.
ClassLoader classLoader = getClass().getClassLoader();
InputStream input = classLoader.getResourceAsStream("/com/example/foo.properties");
// ...
Cependant, la visibilité du fichier de propriétés dépend alors du chargeur de classe en question. Il n'est visible que par le même chargeur de classe que celui qui a chargé la classe. Donc, si la classe est chargée par exemple par le chargeur de classe commun du serveur au lieu du chargeur de classe webapp, et que le fichier de propriétés se trouve à l'intérieur de webapp lui-même, alors il est invisible. Le chargeur de classe de contexte est votre pari le plus sûr, vous pouvez donc placer le fichier de propriétés "partout" dans le chemin de classe et / ou vous avez l'intention de remplacer un fichier fourni par le serveur à partir de la webapp.
2. Mettez-le dans le contenu Web
Pour que vous puissiez le charger ServletContext#getResourceAsStream()avec un chemin relatif au contenu Web:
InputStream input = getServletContext().getResourceAsStream("/WEB-INF/foo.properties");
// ...
Notez que j'ai démontré de placer le fichier dans un /WEB-INFdossier, sinon il aurait été accessible au public par n'importe quel navigateur Web. Notez également que l' ServletContextest dans n'importe quelle HttpServletclasse juste accessible par l'héritage GenericServlet#getServletContext()et Filterpar FilterConfig#getServletContext(). Dans le cas où vous n'êtes pas dans une classe de servlet, il est généralement injectable via @Inject.
3. Mettez-le dans le système de fichiers du disque local
Pour que vous puissiez le charger de la java.iomanière habituelle avec un chemin d'accès absolu au système de fichiers du disque local:
InputStream input = new FileInputStream("/absolute/path/to/foo.properties");
// ...
Notez l'importance d'utiliser un chemin absolu. Les chemins d'accès relatifs au système de fichiers du disque local sont une solution absolue dans une application Web Java EE. Voir aussi le premier lien "Voir aussi" ci-dessous.
Lequel choisir?
Il suffit de peser les avantages / inconvénients selon votre propre opinion de la maintenabilité.
Si les fichiers de propriétés sont "statiques" et n'ont jamais besoin d'être modifiés pendant l'exécution, vous pouvez les conserver dans le WAR.
Si vous préférez pouvoir modifier les fichiers de propriétés depuis l'extérieur de l'application Web sans avoir à reconstruire et redéployer le WAR à chaque fois, alors placez-le dans le chemin de classe en dehors du projet (si nécessaire, ajoutez le répertoire au chemin de classe).
Si vous préférez pouvoir modifier les fichiers de propriétés par programme depuis l'intérieur de l'application Web à l'aide de la Properties#store()méthode, placez-le en dehors de l'application Web. Comme le Properties#store()requiert un Writer, vous ne pouvez pas vous déplacer en utilisant un chemin d'accès au système de fichiers disque. Ce chemin peut à son tour être transmis à l'application Web en tant qu'argument VM ou propriété système. Par précaution, ne jamais utilisergetRealPath() . Toutes les modifications dans le dossier de déploiement seront perdues lors d'un redéploiement pour la simple raison que les modifications ne sont pas reflétées dans le fichier WAR d'origine.
Voir également: