Chemin relatif vers un fichier

Version imprimable

03/11/2009, 19h56
buxbux

Chemin relatif vers un fichier

Bonjour,
Je n'arrive pas a récupérer un fichier xml avec mon application. En testant mon application avec NetBeans, le fichier est trouvé correctement. Mais dés lors que j'exécute le logiciel après construction, il ne chercher plus le fichier en fonction de l'exécutable Java.
Voici le code:
Je récupère mon fichier comme ceci:

Citation:

document = sxb.build(new File("data.xml"));

Le fichier se trouve physiquement a la racine du dossier de mon projet.
Donc, comme dit au dessus, lorsque je lance mon projet dans NetBeans, aucun soucis. Mais lorsque j'exécute l'application après construction, il cherche le fichier dans mon répertoire personnel:

Citation:

/home/bux/data.xml

Même chose si je précise "./data.xml" (il cherche sur /home/bux/./data.xml)
Comment est-ce que je peux faire ? Et est-ce normal ?
04/11/2009, 09h35
adiGuba

Salut,

Citation:

Envoyé par buxbux

Mais dés lors que j'exécute le logiciel après construction, il ne chercher plus le fichier en fonction de l'exécutable Java.

Les chemins relatifs le sont par rapport au répertoire de travail, qui peut varier selon la manière dont tu lances le programmes...

Donc c'est tout à fait normal !

a++
04/11/2009, 12h27
buxbux

Ok =)
Mais a ce moment là, comment puis-je utiliser des fichiers que je souhaite placer dans le répertoire de l'application construite ?
04/11/2009, 15h13
kossistus

Citation:

Envoyé par buxbux

Ok =)
Mais a ce moment là, comment puis-je utiliser des fichiers que je souhaite placer dans le répertoire de l'application construite ?

Salut,
Une idée est de mettre le fichier dans ton classpath.
Une autre façon est de créer une variable d'environnement genre variable_env =repertoire ou tu vas déposer ton fichier. Et dans ton appli tu récupères ta variable donc ton répertoire et tu utilises ton fichier.Bien attendu il faut les bons droits sur le répertoire et le fichier.
Cordialement.
04/11/2009, 21h19
buxbux

Citation:

Une idée est de mettre le fichier dans ton classpath.
Une autre façon est de créer une variable d'environnement [...]

Du genre créer un package et y placer le fichier en question ? Comment je peux ensuite pointer sur le fichier ?
Je peux voir ceci:

Citation:

Pour définir la variable d'environnement classpath

* sous Linux, il faut utiliser la commande suivante :
export CLASSPATH = <repertoire>:<repertoire>;...

par exemple :
export CLASSPATH = /home/jeff/java:/usr/lib/jdkx.x.x/lib/classes.zip:...

* sous Windows, il faut utiliser la commande suivante :
SET CLASSPATH = <repertoire>;<repertoire>;...

par exemple :
SET CLASSPATH = c:\java;c:\jdkx.x.x\lib\classes.zip;...

Puis-je faire ça d'une manière relative a l'exécutable du logiciel ?

Enfin ne gros ne pas réussir a pointer sur mon fichier data.xml est vraiment le soucis qui bloque l'utilisation de mon logiciel erf
07/11/2009, 01h03
kossistus

pour récuperer ton fichier tu peux faire (que j'ai trouvé au hasard)

Code:

String nomFichier = Thread.currentThread().getContextClassLoader().getResource("unfichier.xml").getFile()

Citation:

Envoyé par kossistus

pour récuperer ton fichier tu peux faire (que j'ai trouvé au hasard)

Code:

String nomFichier = Thread.currentThread().getContextClassLoader().getResource("unfichier.xml").getFile()

Erf:
Code:

1 2 3 4 5 try { document = sxb.build(new File(Thread.currentThread().getContextClassLoader().getResource("data.xml").getFile())); } catch(Exception e){ JOptionPane.showMessageDialog(null,"Impossible de trouver le fichier data.xml ("+e+")"); }
Citation:

Impossible de trouver le fichier data.xml (java.lang.NullPointerException)

:/

J'ai testé aussi

Code:

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
 
import java.io.File;
 
import org.jdom.Element;
import org.jdom.input.SAXBuilder;
 
public class ConstruireAvecSaxBuilder {
	static org.jdom.Document document;
	  static Element racine;
 
	public static void main(String[] args) {
		String nomFichier = Thread.currentThread().getContextClassLoader().getResource("fichier.xml").getFile();
		  SAXBuilder sxb = new SAXBuilder();
 
 
		      try
		      {
 
		         document = sxb.build(new File(nomFichier));
		         System.out.println("document" + document);
 
		      }
		      catch(Exception e){ //blablala ou rien du tout }
 
		   }
 
	}

Et çà marche.
Si ton sxb est instancié ( :roll:) alors ton problème est ailleurs. Ton fichier.xml est bien dans ton classpath (la ou se trouvent tes .java ou .class) ?
Sinon envoi nous ton code.

Alors,
Ca marche du coté NetBeans, mais toujours pas en production erf !
^^

Pour tester donc, j'ai la classe qui créer le document:

Code:

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
package classes;
 
import java.io.File;
 
import javax.swing.JOptionPane;
import org.jdom.Element;
import org.jdom.input.SAXBuilder;
 
public class ConstruireAvecSaxBuilder {
 
	static org.jdom.Document document;
	static Element racine;
 
	public static void Construire() {
 
              try {
 
                  String nomFichier = Thread.currentThread().getContextClassLoader().getResource("data.xml").getFile();
                  SAXBuilder sxb = new SAXBuilder();
 
                 document = sxb.build(new File(nomFichier));
                 System.out.println("document" + document);
 
              } catch(Exception e){
 
                  JOptionPane.showMessageDialog(null,e);
 
              }
 
	}
 
        public static org.jdom.Document getDocument() {
            return document;
        }
 
}

La partie du code qui charge le fichier xml:

Code:

1
2
3
4
5
 
ConstruireAvecSaxBuilder.Construire();
[...]
document = ConstruireAvecSaxBuilder.getDocument();
racine = document.getRootElement();

Sous netBeans ça fonctionne donc niquel, mais en prod:
http://img17.imageshack.us/img17/6399/capture5g.png

Et le fichier data.xml se trouve bien a la racine du dossier "src" (en développement), et donc en production, dans le "Alpotes.jar", a sa racine.

:/

Hum,
Je te propose de contourner le problème avec une variable d'env.
Tu crées cette variable par exemple dans dans un bashrc (en tout accessible pour l'application )
exemple
export MYROOTDIR=/home/bux/data
Tu crees le répertoire /home/bux/data
Tu y mets ton fichier : /home/bux/data/data.xml

et tu teste avec ce petit code.

Code:

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
 
package com.fichier;
 
import java.io.File;
import java.io.IOException;
 
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.input.SAXBuilder;
 
public class Config {
	/** Répertoire racine où se trouvent les fichiers applicatifs */
	public static String ROOT_DIR;
	static org.jdom.Document document;
	  static Element racine;
 
	public static void initConstants() {
              //tout est ici
		ROOT_DIR = System.getenv("MYROOTDIR"); //$NON-NLS-1$
            // c'est bien mon repertoire ?
		System.out.println(" rep en question " + ROOT_DIR );
	}
 
 
	public static void  main (String args []){
		initConstants();
 
		StringBuilder sb = new  StringBuilder().append(ROOT_DIR).append(File.separator).append("data.xml");
		String fichier = sb.toString();
 
 
		  SAXBuilder sxb = new SAXBuilder();
		  try {
			document = sxb.build(new File(fichier));
			//blalalala sur mon fichier
			  System.out.println(" document " + document);
		} catch (JDOMException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
 
 
 
	   }
	}

09/11/2009, 00h21
buxbux

Certes ça devrais fonctionner, le problème c'est que l'idée, c'est de pouvoir accéder au fichier dans un contexte différent. Sur la machine d'un autre utilisateur par exemple :?
09/11/2009, 10h25
kossistus

Citation:

Envoyé par buxbux

Certes ça devrais fonctionner, le problème c'est que l'idée, c'est de pouvoir accéder au fichier dans un contexte différent. Sur la machine d'un autre utilisateur par exemple :?

La 8O je ne comprends plus.
L'application est (ou sera ) en production sur un serveur non ?

Dans ce cas tout ce que tu as à faire c'est d'y créer ta variable par exemple dans /etc/bashrc ou dans un script de lancement, exécuté au démarrage de ton application.
Et pi c'est tout :mrgreen: .

Maintenant si l'utilisateur doit récupérer l'application sur son pc pour installation complète alors la procédure est la même. Il a juste à créer la variable.
Et pi c'est tout :mrgreen: .
C'est bien ce que tu veux faire non ?
Eclaires ma lanterne si je me trompe.
09/11/2009, 11h02
buxbux

Citation:

La je ne comprends plus.
L'application est (ou sera ) en production sur un serveur non ?

Ah non pas du tout ^^ C'est une application Client, qui sera exécuté sur des postes clients avec Système d'exploitations différents, contextes différents ...

Citation:

Maintenant si l'utilisateur doit récupérer l'application sur son pc pour installation complète alors la procédure est la même. Il a juste à créer la variable.
Et pi c'est tout .
C'est bien ce que tu veux faire non ?
Eclaires ma lanterne si je me trompe.

Tu veux dire qu'il n'est pas possible de pointer sur un fichier placé a coté de l'exécutable de mon application ? Je trouve ca très étrange :s

Citation:

Il a juste à créer la variable. Et pi c'est tout .

Comment ça ? ^^
09/11/2009, 11h15
sinok
Bon pour commencer.

Setter le classpath au niveau de l'OS est un mauvaise chose (conflit inter applications, conflit de versions de jars et ainsi de suite), c'est une merde sans nom et une source de bugs sans fin. Le classpath doit être précisé dans le fichier MANIFEST.MF du META-INF de ton jar.

Pour récupérer un élément se trouvant dans le classpath: aller faire un tour dans la FAQ

Pour avoir un endroit où l'on est sur de trouver un fichier au niveau de la config utilisateur:
Code:

1 2 3 String userHomePath System.getProperty("user.home"); String appHomePath = userHome+"/.myApp"; File appHome = new File(appHomePath);
Le user.home renvoyant le répertoire utilisateur, /home/toto sous linux/unix, c:\Documents And Settings\toto sous windows et ainsi de suite.
09/11/2009, 12h21
kossistus

Citation:

Envoyé par buxbux

Ah non pas du tout ^^ C'est une application Client, qui sera exécuté sur des postes clients avec Système d'exploitations différents, contextes différents

Et Ben alors , ou est le problème?
Au risque de me répéter cela ne pose aucun problème, quelque soit l'os il est possible de créer une variable d'env.
.

Citation:

Envoyé par buxbux

Tu veux dire qu'il n'est pas possible de pointer sur un fichier placé a coté de l'exécutable de mon application ? Je trouve ca très étrange :s

Ah bon j'ai dit çà :roll:?
Tu veux lire un fichier placé dans un répertoire (à moins que ce soit dans ton jar, dans ce cas cf classpath).
J'ai donné une piste possible, je ne sais pas si tu l'as essayé ou pas ?

Citation:

Envoyé par buxbux

Comment ça ? ^^

J'essaie d'aider , et pi c'est tout :mouarf:.

Peut être l'idée de sinok correspond mieux à ce que tu veux faire et.
Bon courrage.

Citation:

J'ai donné une piste possible, je ne sais pas si tu l'as essayé ou pas ?

Non, j'espérai ne pas avoir à toucher les variables d'environnement. Je pensais qu'il y avais un moyen simple d'accéder a un fichier placé a coté de l'exécutable sans tout un bric a brac (cf. System.getProperty("user.home")) :D

Citation:

J'essaie d'aider , et pi c'est tout

Ah oui oui, et je t'en remercie :p

En utilisant getClass().getResourceAsStream, je peux accèder facilement a mon fichier xml, contenu dans le .jar Donc ça c'est réglé, merci pour l'aiguillage ^^
Effectivement la FAQ c'est pratique huh ^^

Par contre je ne sais pas trop comment écrire dans ce fichier :s
Code:

1 2 3 4 5 6 7 8 XMLOutputter sortie = new XMLOutputter(Format.getPrettyFormat()); try { sortie.output(document, new FileOutputStream(<<FichierData.xmlEnquestion>>)); } catch (IOException ex) { JOptionPane.showMessageDialog(null,"Impossible d'écrire dans le fichier data.xml ("+ex+")"); Logger.getLogger(Identification.class.getName()).log(Level.SEVERE, null, ex); }
Est-ce possible avec un InputStream/OutputStream? J'ai pas vraiment réussis a vrai dire :/

09/11/2009, 13h48
sinok

Il n'est pas possible d'écrire dans un jar en cours d'exécution. Le fichiers présents dans un jar sont en lecture seule. De plus ta solution posant le fichier dans le répertoire de l'exécutable est foireuse, car suivant les droits de l'utilisateur exécutant l'appli il est possible qu'il ne soit pas autorisé à y écrire. Par exemple sous linux/unix, les applis sont installés dans l'arborescence se situant en dessous de /usr ou /opt. De fait ces répertoires ne sont modifiables que par le superuser (aka root).

De même sur des postes client Windows certains users n'ont pas le droit d'écrire dans ces répertoires (particulièrement en entreprise).

Alors que le user.home est systématiquement accessible en écriture.
D'où le coup du user.home pour stocker les fichiers.

De même éditer les variables d'environnement peut demander certains droits.
09/11/2009, 14h03
buxbux
Citation:

Il n'est pas possible d'écrire dans un jar en cours d'exécution. Le fichiers présents dans un jar sont en lecture seule. De plus ta solution posant le fichier dans le répertoire de l'exécutable est foireuse, car suivant les droits de l'utilisateur exécutant l'appli il est possible qu'il ne soit pas autorisé à y écrire. Par exemple sous linux/unix, les applis sont installés dans l'arborescence se situant en dessous de /usr ou /opt. De fait ces répertoires ne sont modifiables que par le superuser (aka root).

De même sur des postes client Windows certains users n'ont pas le droit d'écrire dans ces répertoires (particulièrement en entreprise).

Ah oui, mauvaise idée alors ^^

Citation:

Alors que le user.home est systématiquement accessible en écriture.
D'où le coup du user.home pour stocker les fichiers.

Je serais donc obligé d'utiliser un script d'installation pour mon application, qui placera le fichier data.xml, par exemple "<userDir>./alpotes/data.xml" (si j'ai bien compris).

==>
Code:

1 2 private String fileSeparator = System.getProperty("file.separator");; private File dataXml = new File(System.getProperty("user.home")+fileSeparator+".alpotes"+fileSeparatorar+"data.xml");
09/11/2009, 14h22
sinok

Tout à fait.

Ou du moins à chaque démarrage vérifier si le fichier existe, et s'il n'existe pas le créer à partir d'un template que tu as dans ton jar.
09/11/2009, 14h36
buxbux

Citation:

et s'il n'existe pas le créer à partir d'un template que tu as dans ton jar

Ah oui, pas bête ^^
eh bien merci beaucoup a vous deux pour tout ça !
Au plaisir =)

Fuseau horaire GMT +2. Il est actuellement 00h38.