Discussion :

[Maine13]

Bonjour,

Je déploie un Projet.WAR sous un serveur tomcat 6 et j'ai besoin de mettre a part un fichier.properties qui contient des paramètres qui peuvent changer à n'importe quel moment.
Y'a t'il un moyen qui permet de récupérer le chemin du projet.war pour pouvoir accéder au fichier.properties pour que je puisse récupérer ces paramètre ???

[DevServlet]

Bonjour,
Tout ce qui est fichier paramètrable pouvant évaluer indépendamment du logiciel qui le sollicite doit être externalisé, en d'autres termes il faut le sortir du war.

[Carhiboux]

Bonjour,
Tout ce qui est fichier paramètrable pouvant évaluer indépendamment du logiciel qui le sollicite doit être externalisé, en d'autres termes il faut le sortir du war.

Pas d'accord.

Si, dans l'idée, c'est plutot séduisant, dans la pratique, c'est un nid à emmerde de ne pas mettre le fichier de properties dans le war.

De toutes facons, ton war n'est rien qu'une archive de plein de fichiers.

Si tu ne mets pas ton fichier properties dans le war, cela implique :

• Que le user va devoir le déployer lui même
• Que le user peut changer le format
• Que le user peut supprimer des cles
• Etc...

Autant de causes qui pourraient empecher ton appli de fonctionner correctement.

A mon sens, mieux vaut inclure le fichier .properties à ton war, quitte à ce qu'il soit modifié ensuite une fois le war déployé si il doit vraiment changer à la volée et encore, dans ce cas là, il vaut probablement mieux passer par une interaction IHM! D'ailleurs, pour que les properties puissent changer à la volée, cela suppose, soit de pouvoir recharger les paramètres à la demande, soit de les recharger à tous les coups, car la pratique habituelle est plutot de lire une bonne fois pour toute les paramètre au lancement de l'appli, et de ne plus trop y regarder après.


Sinon, un autre truc propre, c'est de prévoir plusieurs fichiers de properties par environement, et de constuire le war avec le bon fichier selon les besoins. Mais si tu as besoin de changer les valeurs à la volée, cela ne t'aide pas.

[DevServlet]

Pas d'accord.

C'est tout à fait naturel de pas l'être

Sinon, un autre truc propre, c'est de prévoir plusieurs fichiers de properties par environement, et de constuire le war avec le bon fichier selon les besoins. Mais si tu as besoin de changer les valeurs à la volée, cela ne t'aide pas.

Et donc à chaque nouvel environnement, il faut demander une re-livraison c'est ça? Ou si pour un environnement un paramètre change, à la prochaine livraison on écrase ces paramètres c'est ça?
En général si les paramètres ne doivent plus changer dans le temps, une simple classe de constantes suffit.
D'expérience, les paramètres spécifiques à un environnement, pour des raisons de sécurité doivent être du ressort de l'équipe d'exploitation, et non de l'équipe de l'étude. A ce titre il convient de clairement leur laisser la main.
Une IHM est en effet une solution, mais tout ne peut se mettre dans l'IHM (comme par exemple la datasource principale).

[NoClassDefFound]

Si c'est un fichier properties embarqué dans un war, tu peux y accéder avec une instruction de type getResourceAsStream("myfile.properties"), bref comme un bundle "standard".
Qui plus est, il te faudra effectivement un mécanisme de rechargement du fichier, tu ne vas probablement t'amuser à redémarrer le serveur après chaque modification dans le fichier.

Sinon, un autre truc propre, c'est de prévoir plusieurs fichiers de properties par environement, et de constuire le war avec le bon fichier selon les besoins.

Tout dépend de ce que contient le fichier properties en question. Si ce sont des variables spécifiques à l'environnement comme un chemin,un port, une adresse ip, il est peu probable que l'on te communique ces valeurs pour l'environnement de production. Dans ce cas la suggestion de DevServlet s'applique parfaitement et cela évite d'avoir à générer x packages pour x environnements alors que le binaire est le même.

[Invité]

Cette méthode permet de retrouver les chemins des fichiers properties dans un jar. Il faudra peut être adapter un peu pour un war

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
 
	/**
         * List directory contents for a resource folder. Not recursive.
         * This is basically a brute-force implementation.
         * Works for regular files and also JARs.
         * 
         * @author Greg Briggs
         * @param clazz Any java class that lives in the same place as the resources you want.
         * @param path Should end with "/", but not start with one.
         * @return Just the name of each member item, not the full paths.
         * @throws URISyntaxException 
         * @throws IOException 
         */
	static String[] getResourceListing(Class<?> clazz, String path) throws URISyntaxException, IOException {
 
		URL dirURL = clazz.getClassLoader().getResource(path);
		if (dirURL != null && dirURL.getProtocol().equals("file")) {
			/* A file path: easy enough */
			return new File(dirURL.toURI()).list();
		}
 
		if (dirURL == null) {
			/*
			 * In case of a jar file, we can't actually find a directory. Have
			 * to assume the same jar as clazz.
			 */
			String me = clazz.getName().replace(".", "/") + ".class";
			dirURL = clazz.getClassLoader().getResource(me);
		}
 
		if (dirURL.getProtocol().equals("jar")) {
			/* A JAR path */
			String jarPath = dirURL.getPath().substring(5, dirURL.getPath().indexOf("!")); // strip out only the JAR file
			JarFile jar = new JarFile(URLDecoder.decode(jarPath, "UTF-8"));
			Enumeration<JarEntry> entries = jar.entries(); // gives ALL entries in jar
			Set<String> result = new HashSet<String>(); // avoid duplicates in case it is a subdirectory
			while (entries.hasMoreElements()) {
				String name = entries.nextElement().getName();
				if (name.startsWith(path)) { // filter according to the path
					String entry = name.substring(path.length());
					int checkSubdir = entry.indexOf("/");
					if (checkSubdir >= 0) {
						// if it is a subdirectory, we just return the directory name
						entry = entry.substring(0, checkSubdir);
					}
					result.add(entry);
				}
			}
			jar.close();
			return result.toArray(new String[result.size()]);
		}
		throw new UnsupportedOperationException("Cannot list files for URL " + dirURL);
	}

[Maine13]

Merci pour vos réponses intéressantes.