C'est votre choix. Il y a essentiellement trois façons de procéder dans une archive d'application web Java (WAR) :
1. Mettez-le dans le classpath
Pour que vous puissiez le charger en ClassLoader#getResourceAsStream() avec un chemin relatif à la classe :
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("foo.properties");
// ...
Properties properties = new Properties();
properties.load(input);
Ici foo.properties est censé être placé dans l'une des racines couvertes par le classpath par défaut d'une webapp, par exemple le répertoire /WEB-INF/lib y /WEB-INF/classes le serveur /lib ou les JDK/JRE /lib . Si le fichier de propriétés est spécifique à la webapp, le mieux est de le placer dans le répertoire /WEB-INF/classes . Si vous développez un projet WAR standard dans un IDE, déposez-le dans l'onglet src (le dossier source du projet). Si vous utilisez un projet Maven, déposez-le dans le dossier /main/resources carpeta.
Vous pouvez également le placer quelque part en dehors du classpath par défaut et ajouter son chemin au classpath de l'appserver. Dans Tomcat par exemple, vous pouvez le configurer comme suit shared.loader propriété de Tomcat/conf/catalina.properties .
Si vous avez placé le foo.properties dans une structure de paquetage Java comme com.example alors vous devez le charger comme ci-dessous
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("com/example/foo.properties");
// ...
Notez que le chemin d'accès d'un chargeur de classe contextuel ne doit pas commencer par un nom de domaine. / . Seulement lorsque vous utilisez un chargeur de classe "relatif" tel que SomeClass.class.getClassLoader() alors vous devez effectivement le faire démarrer avec un / .
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 classes en question. Il n'est visible que par le même class loader que celui qui a chargé la classe. Ainsi, si la classe est chargée par exemple par le server common classloader au lieu du webapp classloader, et que le fichier de propriétés se trouve dans la webapp elle-même, il est invisible. Le chargeur de classe contextuel est votre pari le plus sûr si vous pouvez placer le fichier de propriétés "partout" dans le classpath et/ou si vous avez l'intention de pouvoir remplacer un fichier fourni par le serveur à partir de la webapp.
2. Le mettre dans le contenu web
Pour que vous puissiez le charger en ServletContext#getResourceAsStream() avec un chemin relatif au webcontent :
InputStream input = getServletContext().getResourceAsStream("/WEB-INF/foo.properties");
// ...
Notez que j'ai démontré de placer le fichier dans /WEB-INF sinon il aurait été accessible au public par n'importe quel navigateur web. Notez également que le ServletContext est dans tout HttpServlet juste accessible par la classe héritée GenericServlet#getServletContext() et en Filter par FilterConfig#getServletContext() . Au cas où vous ne seriez pas dans une classe de servlet, elle est généralement injectable par l'intermédiaire de @Inject .
3. Le mettre dans le système de fichiers du disque local
Pour que vous puissiez le charger comme d'habitude java.io avec un chemin absolu du 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 relatifs du système de fichiers du disque local sont absolument à proscrire dans une application Web Java EE. Voir aussi le premier lien "Voir aussi" ci-dessous.
Lequel choisir ?
Il suffit de peser les avantages/désavantages en votre sa propre opinion sur la maintenabilité.
Si les fichiers de propriétés sont "statiques" et ne doivent jamais ê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, mettez-le dans le classpath en dehors du projet (si nécessaire, ajoutez le répertoire au classpath).
Si vous préférez être en mesure de modifier les fichiers de propriétés de manière programmatique à partir de l'application web en utilisant Properties#store() en dehors de l'application web. Comme le Properties#store() nécessite un Writer il n'est pas possible d'utiliser un chemin d'accès au système de fichiers du disque. Ce chemin peut à son tour être transmis à l'application Web en tant qu'argument VM ou propriété système. Par précaution, jamais utiliser getRealPath() . Tous les changements dans le dossier de déploiement seront perdus lors d'un redéploiement pour la simple raison que les changements ne sont pas reflétés dans le fichier WAR original.
Voir aussi :
0 votes
JNDI pourrait peut-être être une solution ?