j'ai un problème avec le logger java.util.logging.* de Java
1.4. J'espère que j'aurai des réponse, car habituellement je n'en ai
quasimment jamais quand je pose des questions ici :-)
Dans jre/lib/, il y a un fichier nommé logging.properties qui gère
l'utilitaire de loggage de Java. J'aimerai avoir mon fichier
logging.properties qui est ensuite lu par
LogManager.readConfiguration().
Lorsqu'il est dans un répertoire classique, j'arrive à le lire. Quand
il est dans un répertoire qui est aussi un package (par exemple
projet.config, donc dans le répertoire config qui contient aussi des
classes) je n'arrive pas à le lire. Le système me dit que le fichier
n'existe pas : un File.exists() renvoie faux, et j'ai une exception
quand je tente de lire le fichier puisqu'on ne le trouve pas.
Pourtant il existe. J'essaie d'y accéder aussi bien en donnant le
chemin réel du fichier, qu'en utilisant Class.getRessource(). Et ce
n'est pas un problème de jar, que mes fichiers soient jarrés ou pas
c'est pareil.
Merci d'avance pour vos idées.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
YSMAL Vincent
Bonjour, alors pour changer voila une réponse :))
Bien, commencont par lire la java doc, je cite : If "java.util.logging.config.class" property is not set, then the "java.util.logging.config.file" system property can be used to specify a properties file (in java.util.Properties format). The initial logging configuration will be read from this file
Je crois que c'est clair non . ... ?
Je pense que vous n'avez pas utilisé cette variables, vu le résultat que vous exprimez et si j'en crois encore la javadoc (c'est fou ce qu'on trouve comme info dans la doc, note à moi même, penser à lire la javadoc) : By default, the LogManager reads its initial configuration from a properties file "lib/logging.properties" in the JRE directory
voila voila... un début de réponse avec un axe de recherche, si cela n'est toujours pas suffisant, demandez plus de renseignement. "Vincent Hiribarren" a écrit dans le message de news:
Bonjour,
j'ai un problème avec le logger java.util.logging.* de Java 1.4. J'espère que j'aurai des réponse, car habituellement je n'en ai quasimment jamais quand je pose des questions ici :-)
Dans jre/lib/, il y a un fichier nommé logging.properties qui gère l'utilitaire de loggage de Java. J'aimerai avoir mon fichier logging.properties qui est ensuite lu par LogManager.readConfiguration().
Lorsqu'il est dans un répertoire classique, j'arrive à le lire. Quand il est dans un répertoire qui est aussi un package (par exemple projet.config, donc dans le répertoire config qui contient aussi des classes) je n'arrive pas à le lire. Le système me dit que le fichier n'existe pas : un File.exists() renvoie faux, et j'ai une exception quand je tente de lire le fichier puisqu'on ne le trouve pas.
Pourtant il existe. J'essaie d'y accéder aussi bien en donnant le chemin réel du fichier, qu'en utilisant Class.getRessource(). Et ce n'est pas un problème de jar, que mes fichiers soient jarrés ou pas c'est pareil.
Merci d'avance pour vos idées.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Bonjour,
alors pour changer voila une réponse :))
Bien, commencont par lire la java doc, je cite :
If "java.util.logging.config.class" property is not set, then the
"java.util.logging.config.file" system property can be used to specify a
properties file (in java.util.Properties format). The initial logging
configuration will be read from this file
Je crois que c'est clair non . ... ?
Je pense que vous n'avez pas utilisé cette variables, vu le résultat que
vous exprimez et si j'en crois encore la javadoc (c'est fou ce qu'on trouve
comme info dans la doc, note à moi même, penser à lire la javadoc) :
By default, the LogManager reads its initial configuration from a properties
file "lib/logging.properties" in the JRE directory
voila voila... un début de réponse avec un axe de recherche, si cela n'est
toujours pas suffisant, demandez plus de renseignement.
"Vincent Hiribarren" <vynce@alea.invalid> a écrit dans le message de
news:87oekkuzes.fsf@alea.invalid...
Bonjour,
j'ai un problème avec le logger java.util.logging.* de Java
1.4. J'espère que j'aurai des réponse, car habituellement je n'en ai
quasimment jamais quand je pose des questions ici :-)
Dans jre/lib/, il y a un fichier nommé logging.properties qui gère
l'utilitaire de loggage de Java. J'aimerai avoir mon fichier
logging.properties qui est ensuite lu par
LogManager.readConfiguration().
Lorsqu'il est dans un répertoire classique, j'arrive à le lire. Quand
il est dans un répertoire qui est aussi un package (par exemple
projet.config, donc dans le répertoire config qui contient aussi des
classes) je n'arrive pas à le lire. Le système me dit que le fichier
n'existe pas : un File.exists() renvoie faux, et j'ai une exception
quand je tente de lire le fichier puisqu'on ne le trouve pas.
Pourtant il existe. J'essaie d'y accéder aussi bien en donnant le
chemin réel du fichier, qu'en utilisant Class.getRessource(). Et ce
n'est pas un problème de jar, que mes fichiers soient jarrés ou pas
c'est pareil.
Merci d'avance pour vos idées.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Bien, commencont par lire la java doc, je cite : If "java.util.logging.config.class" property is not set, then the "java.util.logging.config.file" system property can be used to specify a properties file (in java.util.Properties format). The initial logging configuration will be read from this file
Je crois que c'est clair non . ... ?
Je pense que vous n'avez pas utilisé cette variables, vu le résultat que vous exprimez et si j'en crois encore la javadoc (c'est fou ce qu'on trouve comme info dans la doc, note à moi même, penser à lire la javadoc) : By default, the LogManager reads its initial configuration from a properties file "lib/logging.properties" in the JRE directory
voila voila... un début de réponse avec un axe de recherche, si cela n'est toujours pas suffisant, demandez plus de renseignement. "Vincent Hiribarren" a écrit dans le message de news:
Bonjour,
j'ai un problème avec le logger java.util.logging.* de Java 1.4. J'espère que j'aurai des réponse, car habituellement je n'en ai quasimment jamais quand je pose des questions ici :-)
Dans jre/lib/, il y a un fichier nommé logging.properties qui gère l'utilitaire de loggage de Java. J'aimerai avoir mon fichier logging.properties qui est ensuite lu par LogManager.readConfiguration().
Lorsqu'il est dans un répertoire classique, j'arrive à le lire. Quand il est dans un répertoire qui est aussi un package (par exemple projet.config, donc dans le répertoire config qui contient aussi des classes) je n'arrive pas à le lire. Le système me dit que le fichier n'existe pas : un File.exists() renvoie faux, et j'ai une exception quand je tente de lire le fichier puisqu'on ne le trouve pas.
Pourtant il existe. J'essaie d'y accéder aussi bien en donnant le chemin réel du fichier, qu'en utilisant Class.getRessource(). Et ce n'est pas un problème de jar, que mes fichiers soient jarrés ou pas c'est pareil.
Merci d'avance pour vos idées.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Vincent Hiribarren
"YSMAL Vincent" writes:
Bien, commencont par lire la java doc, je cite : If "java.util.logging.config.class" property is not set, then the "java.util.logging.config.file" system property can be used to specify a properties file (in java.util.Properties format). The initial logging configuration will be read from this file
Je crois que c'est clair non . ... ?
Oui, à part que ça me fait strictement la même chose.
J'utilisais LogManager.readConfig(new FileInputStream(nom_fichier)), ça fait la même chose qu'en mettant le nom dans la propritété java.util.logging.config.file (avec après un coup de readConfig() comme il est indiqué dans divers sites webs) : ca me dit que le fichier est introuvable s'il est dans un de mes répertoires de packages, tandis que dans un répertoire autre ça marche bien.
Moi je veux bien que ce soit clair, mais bon... d'ailleurs ils parlent de Preferences API, et en fouillant sur le web on se rend compte que ça n'est pas si clair que ça (en fait il faut utiliser les System.setProperty()).
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Bien, commencont par lire la java doc, je cite :
If "java.util.logging.config.class" property is not set, then the
"java.util.logging.config.file" system property can be used to specify a
properties file (in java.util.Properties format). The initial logging
configuration will be read from this file
Je crois que c'est clair non . ... ?
Oui, à part que ça me fait strictement la même chose.
J'utilisais LogManager.readConfig(new FileInputStream(nom_fichier)),
ça fait la même chose qu'en mettant le nom dans la propritété
java.util.logging.config.file (avec après un coup de readConfig()
comme il est indiqué dans divers sites webs) : ca me dit que le
fichier est introuvable s'il est dans un de mes répertoires de
packages, tandis que dans un répertoire autre ça marche bien.
Moi je veux bien que ce soit clair, mais bon... d'ailleurs ils parlent
de Preferences API, et en fouillant sur le web on se rend compte que
ça n'est pas si clair que ça (en fait il faut utiliser les
System.setProperty()).
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Bien, commencont par lire la java doc, je cite : If "java.util.logging.config.class" property is not set, then the "java.util.logging.config.file" system property can be used to specify a properties file (in java.util.Properties format). The initial logging configuration will be read from this file
Je crois que c'est clair non . ... ?
Oui, à part que ça me fait strictement la même chose.
J'utilisais LogManager.readConfig(new FileInputStream(nom_fichier)), ça fait la même chose qu'en mettant le nom dans la propritété java.util.logging.config.file (avec après un coup de readConfig() comme il est indiqué dans divers sites webs) : ca me dit que le fichier est introuvable s'il est dans un de mes répertoires de packages, tandis que dans un répertoire autre ça marche bien.
Moi je veux bien que ce soit clair, mais bon... d'ailleurs ils parlent de Preferences API, et en fouillant sur le web on se rend compte que ça n'est pas si clair que ça (en fait il faut utiliser les System.setProperty()).
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
YSMAL Vincent
alors pour ce qui est du LogManager.readConfig(new FileInputStream(nom_fichier)) le fichier doit etre à la racine du repertoire des classes ou du jar, exemple : ./monPackage/MaClass.class et bien le fichier properties doit etre : ./logging.properties
Enfin chez moi ca marche comme ca :)) bon courage, j'espère que ca fonctionnera "Vincent Hiribarren" a écrit dans le message de news:
"YSMAL Vincent" writes:
Bien, commencont par lire la java doc, je cite : If "java.util.logging.config.class" property is not set, then the "java.util.logging.config.file" system property can be used to specify a properties file (in java.util.Properties format). The initial logging configuration will be read from this file
Je crois que c'est clair non . ... ?
Oui, à part que ça me fait strictement la même chose.
J'utilisais LogManager.readConfig(new FileInputStream(nom_fichier)), ça fait la même chose qu'en mettant le nom dans la propritété java.util.logging.config.file (avec après un coup de readConfig() comme il est indiqué dans divers sites webs) : ca me dit que le fichier est introuvable s'il est dans un de mes répertoires de packages, tandis que dans un répertoire autre ça marche bien.
Moi je veux bien que ce soit clair, mais bon... d'ailleurs ils parlent de Preferences API, et en fouillant sur le web on se rend compte que ça n'est pas si clair que ça (en fait il faut utiliser les System.setProperty()).
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
alors pour ce qui est du LogManager.readConfig(new
FileInputStream(nom_fichier))
le fichier doit etre à la racine du repertoire des classes ou du jar,
exemple :
./monPackage/MaClass.class
et bien le fichier properties doit etre :
./logging.properties
Enfin chez moi ca marche comme ca :))
bon courage, j'espère que ca fonctionnera
"Vincent Hiribarren" <vynce@alea.invalid> a écrit dans le message de
news:87acw39qdw.fsf@alea.invalid...
Bien, commencont par lire la java doc, je cite :
If "java.util.logging.config.class" property is not set, then the
"java.util.logging.config.file" system property can be used to specify a
properties file (in java.util.Properties format). The initial logging
configuration will be read from this file
Je crois que c'est clair non . ... ?
Oui, à part que ça me fait strictement la même chose.
J'utilisais LogManager.readConfig(new FileInputStream(nom_fichier)),
ça fait la même chose qu'en mettant le nom dans la propritété
java.util.logging.config.file (avec après un coup de readConfig()
comme il est indiqué dans divers sites webs) : ca me dit que le
fichier est introuvable s'il est dans un de mes répertoires de
packages, tandis que dans un répertoire autre ça marche bien.
Moi je veux bien que ce soit clair, mais bon... d'ailleurs ils parlent
de Preferences API, et en fouillant sur le web on se rend compte que
ça n'est pas si clair que ça (en fait il faut utiliser les
System.setProperty()).
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
alors pour ce qui est du LogManager.readConfig(new FileInputStream(nom_fichier)) le fichier doit etre à la racine du repertoire des classes ou du jar, exemple : ./monPackage/MaClass.class et bien le fichier properties doit etre : ./logging.properties
Enfin chez moi ca marche comme ca :)) bon courage, j'espère que ca fonctionnera "Vincent Hiribarren" a écrit dans le message de news:
"YSMAL Vincent" writes:
Bien, commencont par lire la java doc, je cite : If "java.util.logging.config.class" property is not set, then the "java.util.logging.config.file" system property can be used to specify a properties file (in java.util.Properties format). The initial logging configuration will be read from this file
Je crois que c'est clair non . ... ?
Oui, à part que ça me fait strictement la même chose.
J'utilisais LogManager.readConfig(new FileInputStream(nom_fichier)), ça fait la même chose qu'en mettant le nom dans la propritété java.util.logging.config.file (avec après un coup de readConfig() comme il est indiqué dans divers sites webs) : ca me dit que le fichier est introuvable s'il est dans un de mes répertoires de packages, tandis que dans un répertoire autre ça marche bien.
Moi je veux bien que ce soit clair, mais bon... d'ailleurs ils parlent de Preferences API, et en fouillant sur le web on se rend compte que ça n'est pas si clair que ça (en fait il faut utiliser les System.setProperty()).
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
YSMAL Vincent
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas non plus ? genre "./monPackage/logging.properties" j'ai jamais essayé ca
"Vincent Hiribarren" a écrit dans le message de news:
"YSMAL Vincent" writes:
alors pour ce qui est du LogManager.readConfig(new FileInputStream(nom_fichier)) le fichier doit etre à la racine du repertoire des classes ou du jar, exemple : ./monPackage/MaClass.class et bien le fichier properties doit etre : ./logging.properties
Justement. C'est très exactement ce que je disais dans l'article initiale.
J'ai un répertoire Projet, dedans j'ai un répertoire etc/ et un package mon.package. Si mon fichier est dans mon/package/ il est déclaré comme non existant (ce que je ne comprends pas) alors que s'il est dans etc/ ça marche bien. Et moi je veux à la fois comprendre le problème, et forcer la mise en place du fichier dans mon/package/.
Le problème n'est pas que le système de logging ne marche pas (puisque j'arrive à l'utiliser quand mon fichier est dans etc/) mais que mon fichier est déclaré comme non existant (une exception apprait, File.exists() renvoie faux) dans mon/package/ alors qu'il y est.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Oups pardon, j'avais oublié le message de départ ...
Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas
non plus ?
genre "./monPackage/logging.properties"
j'ai jamais essayé ca
"Vincent Hiribarren" <vynce@alea.invalid> a écrit dans le message de
news:871xhf9oeq.fsf@alea.invalid...
alors pour ce qui est du LogManager.readConfig(new
FileInputStream(nom_fichier))
le fichier doit etre à la racine du repertoire des classes ou du jar,
exemple :
./monPackage/MaClass.class
et bien le fichier properties doit etre :
./logging.properties
Justement. C'est très exactement ce que je disais dans l'article initiale.
J'ai un répertoire Projet, dedans j'ai un répertoire etc/ et un package
mon.package. Si mon fichier est dans mon/package/ il est déclaré comme
non existant (ce que je ne comprends pas) alors que s'il est dans etc/
ça marche bien. Et moi je veux à la fois comprendre le problème, et
forcer la mise en place du fichier dans mon/package/.
Le problème n'est pas que le système de logging ne marche pas (puisque
j'arrive à l'utiliser quand mon fichier est dans etc/) mais que mon
fichier est déclaré comme non existant (une exception apprait,
File.exists() renvoie faux) dans mon/package/ alors qu'il y est.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas non plus ? genre "./monPackage/logging.properties" j'ai jamais essayé ca
"Vincent Hiribarren" a écrit dans le message de news:
"YSMAL Vincent" writes:
alors pour ce qui est du LogManager.readConfig(new FileInputStream(nom_fichier)) le fichier doit etre à la racine du repertoire des classes ou du jar, exemple : ./monPackage/MaClass.class et bien le fichier properties doit etre : ./logging.properties
Justement. C'est très exactement ce que je disais dans l'article initiale.
J'ai un répertoire Projet, dedans j'ai un répertoire etc/ et un package mon.package. Si mon fichier est dans mon/package/ il est déclaré comme non existant (ce que je ne comprends pas) alors que s'il est dans etc/ ça marche bien. Et moi je veux à la fois comprendre le problème, et forcer la mise en place du fichier dans mon/package/.
Le problème n'est pas que le système de logging ne marche pas (puisque j'arrive à l'utiliser quand mon fichier est dans etc/) mais que mon fichier est déclaré comme non existant (une exception apprait, File.exists() renvoie faux) dans mon/package/ alors qu'il y est.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Vincent Hiribarren
"YSMAL Vincent" writes:
alors pour ce qui est du LogManager.readConfig(new FileInputStream(nom_fichier)) le fichier doit etre à la racine du repertoire des classes ou du jar, exemple : ./monPackage/MaClass.class et bien le fichier properties doit etre : ./logging.properties
Justement. C'est très exactement ce que je disais dans l'article initiale.
J'ai un répertoire Projet, dedans j'ai un répertoire etc/ et un package mon.package. Si mon fichier est dans mon/package/ il est déclaré comme non existant (ce que je ne comprends pas) alors que s'il est dans etc/ ça marche bien. Et moi je veux à la fois comprendre le problème, et forcer la mise en place du fichier dans mon/package/.
Le problème n'est pas que le système de logging ne marche pas (puisque j'arrive à l'utiliser quand mon fichier est dans etc/) mais que mon fichier est déclaré comme non existant (une exception apprait, File.exists() renvoie faux) dans mon/package/ alors qu'il y est.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
alors pour ce qui est du LogManager.readConfig(new
FileInputStream(nom_fichier))
le fichier doit etre à la racine du repertoire des classes ou du jar,
exemple :
./monPackage/MaClass.class
et bien le fichier properties doit etre :
./logging.properties
Justement. C'est très exactement ce que je disais dans l'article initiale.
J'ai un répertoire Projet, dedans j'ai un répertoire etc/ et un package
mon.package. Si mon fichier est dans mon/package/ il est déclaré comme
non existant (ce que je ne comprends pas) alors que s'il est dans etc/
ça marche bien. Et moi je veux à la fois comprendre le problème, et
forcer la mise en place du fichier dans mon/package/.
Le problème n'est pas que le système de logging ne marche pas (puisque
j'arrive à l'utiliser quand mon fichier est dans etc/) mais que mon
fichier est déclaré comme non existant (une exception apprait,
File.exists() renvoie faux) dans mon/package/ alors qu'il y est.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
alors pour ce qui est du LogManager.readConfig(new FileInputStream(nom_fichier)) le fichier doit etre à la racine du repertoire des classes ou du jar, exemple : ./monPackage/MaClass.class et bien le fichier properties doit etre : ./logging.properties
Justement. C'est très exactement ce que je disais dans l'article initiale.
J'ai un répertoire Projet, dedans j'ai un répertoire etc/ et un package mon.package. Si mon fichier est dans mon/package/ il est déclaré comme non existant (ce que je ne comprends pas) alors que s'il est dans etc/ ça marche bien. Et moi je veux à la fois comprendre le problème, et forcer la mise en place du fichier dans mon/package/.
Le problème n'est pas que le système de logging ne marche pas (puisque j'arrive à l'utiliser quand mon fichier est dans etc/) mais que mon fichier est déclaré comme non existant (une exception apprait, File.exists() renvoie faux) dans mon/package/ alors qu'il y est.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Vincent Hiribarren
"YSMAL Vincent" writes:
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas non plus ?
Evidemment.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Je sais que le nom de la ressource est bonne, car j'ai une exception qui apparait en me disant que le fichier n'existe pas en me donnant le nom de fichier créé par le Class.getRessource().toString().
J'ai une eu sorte d'illumination, et j'ai mis en deuxième paramètre du setProperty le nom réel (donc le copié collé du nom de fichier donné par l'exception) et ça marche !
Je ne comprends absolument pas. :-( Si quelqu'un a une idée...
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Je sais que le nom de la ressource est bonne, car j'ai une exception
qui apparait en me disant que le fichier n'existe pas en me donnant le
nom de fichier créé par le Class.getRessource().toString().
J'ai une eu sorte d'illumination, et j'ai mis en deuxième paramètre du
setProperty le nom réel (donc le copié collé du nom de fichier donné
par l'exception) et ça marche !
Je ne comprends absolument pas. :-(
Si quelqu'un a une idée...
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Je sais que le nom de la ressource est bonne, car j'ai une exception qui apparait en me disant que le fichier n'existe pas en me donnant le nom de fichier créé par le Class.getRessource().toString().
J'ai une eu sorte d'illumination, et j'ai mis en deuxième paramètre du setProperty le nom réel (donc le copié collé du nom de fichier donné par l'exception) et ça marche !
Je ne comprends absolument pas. :-( Si quelqu'un a une idée...
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Vincent Hiribarren
Vincent Hiribarren writes:
"YSMAL Vincent" writes:
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire "src" en racine).
Par contre mon problème reste, et quelque chose doit m'échapper en Java, mais je ne vois pas quoi. J'ai un :
Je sais que le nom de la ressource est bonne, car j'ai une exception qui apparait en me disant que le fichier n'existe pas en me donnant le nom de fichier créé par le Class.getRessource().toString().
J'ai eu une eu sorte d'illumination, et j'ai mis en deuxième paramètre du setProperty le nom réel (donc le copié collé du nom de fichier donné par l'exception) et ça marche !
Je ne comprends absolument pas. :-( Si quelqu'un a une idée...
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Oups pardon, j'avais oublié le message de départ ...
Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas
non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je
bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire
"src" en racine).
Par contre mon problème reste, et quelque chose doit m'échapper en
Java, mais je ne vois pas quoi. J'ai un :
Je sais que le nom de la ressource est bonne, car j'ai une exception
qui apparait en me disant que le fichier n'existe pas en me donnant le
nom de fichier créé par le Class.getRessource().toString().
J'ai eu une eu sorte d'illumination, et j'ai mis en deuxième paramètre du
setProperty le nom réel (donc le copié collé du nom de fichier donné
par l'exception) et ça marche !
Je ne comprends absolument pas. :-(
Si quelqu'un a une idée...
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire "src" en racine).
Par contre mon problème reste, et quelque chose doit m'échapper en Java, mais je ne vois pas quoi. J'ai un :
Je sais que le nom de la ressource est bonne, car j'ai une exception qui apparait en me disant que le fichier n'existe pas en me donnant le nom de fichier créé par le Class.getRessource().toString().
J'ai eu une eu sorte d'illumination, et j'ai mis en deuxième paramètre du setProperty le nom réel (donc le copié collé du nom de fichier donné par l'exception) et ça marche !
Je ne comprends absolument pas. :-( Si quelqu'un a une idée...
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Vincent Hiribarren
[Pfou, double supersedes]
Vincent Hiribarren writes:
"YSMAL Vincent" writes:
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire "src" en racine).
J'ai compris mon problème, il était légèrement subtil.
En fait, un "file:/" se fout devant le nom du fichier, car on convertit une URL en String. Je ne m'en étais pas rendu compte car je pensais que c'était normal, alors qu'en fait Java cherchait un fichier commençant par "file:". D'où mon tatonnement.
Merci, ce dialogue m'aura d'une manière ou d'une autre mis sur la voie.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Oups pardon, j'avais oublié le message de départ ...
Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas
non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je
bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire
"src" en racine).
J'ai compris mon problème, il était légèrement subtil.
En fait, un "file:/" se fout devant le nom du fichier, car on
convertit une URL en String. Je ne m'en étais pas rendu compte car je
pensais que c'était normal, alors qu'en fait Java cherchait un fichier
commençant par "file:". D'où mon tatonnement.
Merci, ce dialogue m'aura d'une manière ou d'une autre mis sur la voie.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire "src" en racine).
J'ai compris mon problème, il était légèrement subtil.
En fait, un "file:/" se fout devant le nom du fichier, car on convertit une URL en String. Je ne m'en étais pas rendu compte car je pensais que c'était normal, alors qu'en fait Java cherchait un fichier commençant par "file:". D'où mon tatonnement.
Merci, ce dialogue m'aura d'une manière ou d'une autre mis sur la voie.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
YSMAL Vincent
Bonsoir, et bien ca me rassure, et pas de soucis, pas besoin de s'excuser, tout ceci était un dialogue dans le but de faire avancer tous les intervenants. Donc c'est une bonne chose si ca fonctionne, ca va permettre de continuer héhé Bon courage pour la suite.
"Vincent Hiribarren" a écrit dans le message de news:
[Pfou, double supersedes]
Vincent Hiribarren writes:
"YSMAL Vincent" writes:
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas
non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire "src" en racine).
J'ai compris mon problème, il était légèrement subtil.
En fait, un "file:/" se fout devant le nom du fichier, car on convertit une URL en String. Je ne m'en étais pas rendu compte car je pensais que c'était normal, alors qu'en fait Java cherchait un fichier commençant par "file:". D'où mon tatonnement.
Merci, ce dialogue m'aura d'une manière ou d'une autre mis sur la voie.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
Bonsoir,
et bien ca me rassure, et pas de soucis, pas besoin de s'excuser,
tout ceci était un dialogue dans le but de faire avancer tous les
intervenants.
Donc c'est une bonne chose si ca fonctionne, ca va permettre de continuer
héhé
Bon courage pour la suite.
"Vincent Hiribarren" <vynce@alea.invalid> a écrit dans le message de
news:87hdqb85sc.fsf@alea.invalid...
Oups pardon, j'avais oublié le message de départ ...
Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche
pas
non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je
bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire
"src" en racine).
J'ai compris mon problème, il était légèrement subtil.
En fait, un "file:/" se fout devant le nom du fichier, car on
convertit une URL en String. Je ne m'en étais pas rendu compte car je
pensais que c'était normal, alors qu'en fait Java cherchait un fichier
commençant par "file:". D'où mon tatonnement.
Merci, ce dialogue m'aura d'une manière ou d'une autre mis sur la voie.
--
Un peu d'aléa dans ce monde de fatalité.
http://www.alea.net/usenet/
Bonsoir, et bien ca me rassure, et pas de soucis, pas besoin de s'excuser, tout ceci était un dialogue dans le but de faire avancer tous les intervenants. Donc c'est une bonne chose si ca fonctionne, ca va permettre de continuer héhé Bon courage pour la suite.
"Vincent Hiribarren" a écrit dans le message de news:
[Pfou, double supersedes]
Vincent Hiribarren writes:
"YSMAL Vincent" writes:
Oups pardon, j'avais oublié le message de départ ... Bon déjà c'est rassurant , je suppose que le chemin relatif ne marche pas
non plus ?
Evidemment.
Pardon, mes excuses, en fait ca marche, j'en donnais un mauvais (je bosse sous Eclipse et j'avais oublié que j'avais créé un répertoire "src" en racine).
J'ai compris mon problème, il était légèrement subtil.
En fait, un "file:/" se fout devant le nom du fichier, car on convertit une URL en String. Je ne m'en étais pas rendu compte car je pensais que c'était normal, alors qu'en fait Java cherchait un fichier commençant par "file:". D'où mon tatonnement.
Merci, ce dialogue m'aura d'une manière ou d'une autre mis sur la voie.
-- Un peu d'aléa dans ce monde de fatalité. http://www.alea.net/usenet/
