Y'a une belle erreur quand on lance l'appli : GRAVE: java.io.FileNotFoundException: /home/chemit/projets/nuiton/plugins/.properties (Aucun fichier ou dossier de ce type) java.io.FileNotFoundException: /home/chemit/projets/nuiton/plugins/.properties (Aucun fichier ou dossier de ce type) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:179) at java.io.FileOutputStream.<init>(FileOutputStream.java:131) at org.nuiton.mapstoragemanager.pluginloader.PluginLoader.<init>(PluginLoader.java:72) at org.nuiton.mapstoragemanager.ui.engine.ApplicationEngine.loadPlugins(ApplicationEngine.java:102) at org.nuiton.mapstoragemanager.Main.<init>(Main.java:59) at org.nuiton.mapstoragemanager.Main.main(Main.java:82) De plus log4j n'est pas configuré. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Bonjour, L'erreur pour le fichier non trouvé (.properties) "est étonnante". Normalement si le fichier n'existe pas (il ne doit pas se trouver sur le svn, puisqu'il s'agit d'un fichier de "configuration" pour les plugins), ce fichier est créé automatiquement. Concernant Log4J, nous ne l'avons pas utilisé, en fait, au commit 36 florian desbois nous a donné un exemple de test unitaire ( http://svn.nuiton.org/repositories/entry/mapstoragemanager/trunk/src/test/ja...) utilisant le logger apache, ainsi c'est celui-ci que nous avons utilisé : import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; Cordialement. -- Dorian Langlais.
Le Wed, 7 Apr 2010 16:11:01 +0200, Dorian Langlais <dorian.langlais@gmail.com> a écrit :
Bonjour,
L'erreur pour le fichier non trouvé (.properties) "est étonnante". Normalement si le fichier n'existe pas (il ne doit pas se trouver sur le svn, puisqu'il s'agit d'un fichier de "configuration" pour les plugins), ce fichier est créé automatiquement.
Concernant Log4J, nous ne l'avons pas utilisé, en fait, au commit 36 florian desbois nous a donné un exemple de test unitaire ( http://svn.nuiton.org/repositories/entry/mapstoragemanager/trunk/src/test/ja...) utilisant le logger apache, ainsi c'est celui-ci que nous avons utilisé :
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
comme quoi des fois vaut mieux se taire que dire des bêtises :) le logger de commons-logging permet de s'abstraire du logguer qui sera en réelle utilisé dans l'application. L'idée étant de pouvoir facilement changer de logger sans à avoir à modifier le code. Ceci étant dit, il faut donc utiliser dans l'application explicitement un logger. Chez code, nous avons fait le choix de log4j, il faut donc avoir une dépendance sur log4 en scope runtime, sinon il utilise par défaut le logger proposé dans la jre (celui de java) qui n'est pas très configurable. Maintenant tu pourras pas dire que tu sais pô ;) J'ai pas compris non plus le pourquoi des 2 modules d'import-export Xml, pour moi les 4 classes doivent être dans le module msm (qui devrait s'appeler autrement car c'est vraiment pas parlant msm : au moins un truc qui dit que c'est du swing ou main , donc au choix msm-swing ou msm-main mais c SECONDAIRE :)) Si tu n'y vois pas d'objections, je vais rapatrier les dites 4 classes dans msm et supprimer les 2 modules. Au fait, toujours des problèmes de traduction sur 7 ? Si oui, ça m'intéresse de régler le problème mais j'ai pas de 7 donc je peux pas faire un diagnostic de se qui déconne, à toi de m'aider ;)
Cordialement.
-- Dorian Langlais.
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Re, Le 7 avril 2010 16:24, Tony Chemit <chemit@codelutin.com> a écrit :
Le Wed, 7 Apr 2010 16:11:01 +0200, Dorian Langlais <dorian.langlais@gmail.com> a écrit :
Bonjour,
L'erreur pour le fichier non trouvé (.properties) "est étonnante". Normalement si le fichier n'existe pas (il ne doit pas se trouver sur le svn, puisqu'il s'agit d'un fichier de "configuration" pour les plugins), ce fichier est créé automatiquement.
Concernant Log4J, nous ne l'avons pas utilisé, en fait, au commit 36 florian desbois nous a donné un exemple de test unitaire (
http://svn.nuiton.org/repositories/entry/mapstoragemanager/trunk/src/test/ja... )
utilisant le logger apache, ainsi c'est celui-ci que nous avons utilisé :
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
comme quoi des fois vaut mieux se taire que dire des bêtises :)
^^
le logger de commons-logging permet de s'abstraire du logguer qui sera en réelle utilisé dans l'application. L'idée étant de pouvoir facilement changer de logger sans à avoir à modifier le code.
Ceci étant dit, il faut donc utiliser dans l'application explicitement un logger. Chez code, nous avons fait le choix de log4j, il faut donc avoir une dépendance sur log4 en scope runtime, sinon il utilise par défaut le logger proposé dans la jre (celui de java) qui n'est pas très configurable.
Maintenant tu pourras pas dire que tu sais pô ;)
Ok, on en apprend tous les jours ^^.
J'ai pas compris non plus le pourquoi des 2 modules d'import-export Xml, pour moi les 4 classes doivent être dans le module msm (qui devrait s'appeler autrement car c'est vraiment pas parlant msm : au moins un truc qui dit que c'est du swing ou main , donc au choix msm-swing ou msm-main mais c SECONDAIRE :))
En fait, l'idée était de permettre à n'importe qui de réaliser son plugin d'import et/ou d'export (par exemple à partir d'un fichier csv...).
Si tu n'y vois pas d'objections, je vais rapatrier les dites 4 classes dans msm et supprimer les 2 modules.
C'est à vous de voir, normalement rien n'empêche qui que ce soit de créer lui aussi son plugin d'import/export par la suite. Au fait, toujours des problèmes de traduction sur 7 ? Si oui, ça m'intéresse de régler le problème mais j'ai pas de 7 donc je peux
pas faire un diagnostic de se qui déconne, à toi de m'aider ;)
Oui, ça n'a jamais marché chez moi (avec Windows 7 et les JDK 1.6u18 32/64 bits). D'ailleurs, à la fac sous Windows XP (32 bits), nous avions le même soucis. Je n'ai pas vraiment de piste pour vous aider sur ce point étant donné qu'il n'y a aucun log de warning ou d'info lié au sujet (au début il y avait un soucis de "bundle" de traduction qui n'était pas correctement choisis... mais la correction de celui-ci n'a pas réparé notre soucis). De même votre démo sur jaxx affiche uniquement les clés i18n chez moi (j'ai un doute au sujet de la fac sur XP à ce sujet). Justement, la seule piste que je pourrais vous fournir, c'est que sur mon PC je ne dois pas avoir ce qu'il faut pour "java web start" -- Dorian Langlais, 06 17 21 04 99
Le Wed, 7 Apr 2010 18:22:59 +0200, Dorian Langlais <dorian.langlais@gmail.com> a écrit :
Re,
Le 7 avril 2010 16:24, Tony Chemit <chemit@codelutin.com> a écrit :
Le Wed, 7 Apr 2010 16:11:01 +0200, Dorian Langlais <dorian.langlais@gmail.com> a écrit :
Bonjour,
L'erreur pour le fichier non trouvé (.properties) "est étonnante". Normalement si le fichier n'existe pas (il ne doit pas se trouver sur le svn, puisqu'il s'agit d'un fichier de "configuration" pour les plugins), ce fichier est créé automatiquement.
Concernant Log4J, nous ne l'avons pas utilisé, en fait, au commit 36 florian desbois nous a donné un exemple de test unitaire (
http://svn.nuiton.org/repositories/entry/mapstoragemanager/trunk/src/test/ja... )
utilisant le logger apache, ainsi c'est celui-ci que nous avons utilisé :
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
comme quoi des fois vaut mieux se taire que dire des bêtises :)
^^
le logger de commons-logging permet de s'abstraire du logguer qui sera en réelle utilisé dans l'application. L'idée étant de pouvoir facilement changer de logger sans à avoir à modifier le code.
Ceci étant dit, il faut donc utiliser dans l'application explicitement un logger. Chez code, nous avons fait le choix de log4j, il faut donc avoir une dépendance sur log4 en scope runtime, sinon il utilise par défaut le logger proposé dans la jre (celui de java) qui n'est pas très configurable.
Maintenant tu pourras pas dire que tu sais pô ;)
Ok, on en apprend tous les jours ^^.
J'ai pas compris non plus le pourquoi des 2 modules d'import-export Xml, pour moi les 4 classes doivent être dans le module msm (qui devrait s'appeler autrement car c'est vraiment pas parlant msm : au moins un truc qui dit que c'est du swing ou main , donc au choix msm-swing ou msm-main mais c SECONDAIRE :))
En fait, l'idée était de permettre à n'importe qui de réaliser son plugin d'import et/ou d'export (par exemple à partir d'un fichier csv...).
Si tu n'y vois pas d'objections, je vais rapatrier les dites 4 classes dans msm et supprimer les 2 modules.
C'est à vous de voir, normalement rien n'empêche qui que ce soit de créer lui aussi son plugin d'import/export par la suite.
Le fait de supprimer les deux modules et de garder les classes dans le module principale changera-t-il quelque chose ? d'autant que les deux font la même choses avec des libs différentes, à moins que je ne me trompe...
Au fait, toujours des problèmes de traduction sur 7 ?
Si oui, ça m'intéresse de régler le problème mais j'ai pas de 7 donc je peux
pas faire un diagnostic de se qui déconne, à toi de m'aider ;)
Oui, ça n'a jamais marché chez moi (avec Windows 7 et les JDK 1.6u18 32/64 bits). D'ailleurs, à la fac sous Windows XP (32 bits), nous avions le même soucis. Je n'ai pas vraiment de piste pour vous aider sur ce point étant donné qu'il n'y a aucun log de warning ou d'info lié au sujet (au début il y avait un soucis de "bundle" de traduction qui n'était pas correctement choisis... mais la correction de celui-ci n'a pas réparé notre soucis).
Il faut que tu arrives à configurer log4j et tu mets org.nuiton.i18n en DEBUG Puis tu m'envoies la trace et là je pourrais savoir ce qui se passe. En log INFO ou WARNING, c'est pas suffisant pour comprendre d'où vient l'erreur.
De même votre démo sur jaxx affiche uniquement les clés i18n chez moi (j'ai un doute au sujet de la fac sur XP à ce sujet). Justement, la seule piste que je pourrais vous fournir, c'est que sur mon PC je ne dois pas avoir ce qu'il faut pour "java web start"
Mouai piste un peu légère à mon gout, même si j'aime bien ton vouvoyement :) On peut peut-être se tutoyer tu sais... -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Re, Le fait de supprimer les deux modules et de garder les classes dans le
module principale changera-t-il quelque chose ? d'autant que les deux font la même choses avec des libs différentes, à moins que je ne me trompe...
étant donné qu'il s'agit de plugin, actuellement, ils ne sont chargé que si on les "charge" (avec notre plugin loader qui utilise le service loader...). Il faut que tu arrives à configurer log4j et tu mets org.nuiton.i18n en
DEBUG Puis tu m'envoies la trace et là je pourrais savoir ce qui se passe. En log INFO ou WARNING, c'est pas suffisant pour comprendre d'où vient l'erreur.
Je regarderai ça quand j'aurai un peu de temps.
De même votre démo sur jaxx affiche uniquement les clés i18n chez moi (j'ai
un doute au sujet de la fac sur XP à ce sujet). Justement, la seule piste que je pourrais vous fournir, c'est que sur mon PC je ne dois pas avoir ce qu'il faut pour "java web start"
Mouai piste un peu légère à mon gout, même si j'aime bien ton vouvoyement :) On peut peut-être se tutoyer tu sais...
C'est sûr, mais c'est la seule piste que j'ai, sinon, si vous avec un XP sous la main, peut-être commencer par voir si vous rencontrez le soucis. Oui, en fait je dis/disais vous pour parler de l'équipe de code lutin. Mais si tu es le seul à bosser sur le projet, je peux passer au mode 2ème personne du singulier ^^. -- Dorian Langlais, 06 17 21 04 99
participants (2)
-
Dorian Langlais -
Tony Chemit