Salut,
voilà, j'ai des problème car mon application cale quelquefois sur un PC, et comme elle n'est pas exécutée en console, je ne vois pas l'exception ...
alors quel est le moyen le plus simple de pouvoir consulter le journal des évènement ?
J'ai trouvé l'API Logging qui est très bien, seulement, je n'arrive pas à le lire, du moins pas clairement ...

Donc ma question est :

- Comment lire un fichier logs généré par l'API Loggin ?
- Logging est-il assez performant ?
- N'y a-t-il pas moyen d'intercepté tout ce qui sort vers la console pour le mettre dans ce fichier log ?

Voilà, merci d'avance ...

Salut.
Je ne connait pas l'api longgin mais pour la qestuion :
"N'y a-t-il pas moyen d'intercepté tout ce qui sort vers la console pour le mettre dans ce fichier log ?"
tu peux simplement définir une méthode static dans une class utilitaire que tu appelles ecrireLog qui prend en argument une chaine ou un objet (ça dépend ce que tu veux écrire) et qui écris dans un fichier banal.

Mais je suis certains que tu dois trouver ton bonheur plus simplement avec loggin. Tu as regardé ceci :
ftp://ftp-developpez.com/cyberzoide/java/logging.pdf
et cela :
http://download.oracle.com/javase/1.4. [...] overview.html

Oui, il dise comment écrire mais pas comment lire.
a mon avis, il faut lire ça soi-même ...

Et même, je trouve qu'il y a beaucoup de contenu, ça doit être plutôt lourd ...

Je me demande si je ne vais pas faire ma propre classe qui sera la plus performante, pour la bonne raison que je ne compte pas écrire le journal immédiatement dans le fichier, mais stocké ça en mémoire vive, et écrire tout ça à la fermeture du logiciel et en cas d'exception ...

Qu'en penses-tu ? ça ralentirait beaucoup moins non ?
Le seul problème, c'est si le résultat dans la mémoire vive augmente trop ...
Là, ça risque de bouffer trop de mémoire ... Mais il y a peu de chance quand même, et on peu faire quelque chose comme vider le tampon après 500 évènements pour être s^r que le tampon ne prennent pas de dimensions démesurées ...

Il est clair que ça ralentit moi d'éviter les entrées sorties. Après ça dépend de ton application. Parce que si ton appli plante brutalement (c'est pour ça qu'on dit planter) alors rien ne sera sauvegardé et du coup ton reporting ne servira à rien.
Y a encore un autre cas à disinguer. C'est si tu veux simplement stocker les exceptions qui surgissent. Vu qu'en thoérie ça ne doit pas arriver sauf rare cas, alors je te conseille d'écrire directement dans ton fichier parce que ça arrivera presque jamais => pas de pertes de perfs.

Tout dépend de tes besoins.

P.S: en dev tu peux lancer ton jar via l'invite de commande et ainsi avoir tous tes messages affichés sur la console si c'est uniquement ceci que tu veux et pas un suivis qui dure dans le temps...

Hum ...
Oui, si ça plante brutalement, mais si ça plante comme ça, je ne pourrais pas non plus écrire !
Donc ce que je peu faire, c'est un niveau d'importance.
Si c'est grave, j'écris immédiatement, si c'est juste des infos ou si ça ne peu pas nuire au bon déroulement, j'écris rien ...

Mais je comprends, imaginons que j'ai oublier de capturer une exception, ce qui est dans le tampon sera perdu ...

C'est vrai que c'est un gros pb ...
euh ... l'écouteur WindowListener peut-il détecter un plantage ?
Dan tout les cas, l'utilisateur devra bien fermer son appli un jour ... et là, si j'arrive à écouter cette fermeture ...

"Oui, si ça plante brutalement, mais si ça plante comme ça, je ne pourrais pas non plus écrire !"
sauf que tout ce que tu auras en mémoire sera perdu alors que tu aurais pu l'écrire au fur et à mesure
Avec windows listener tu peux écouter la fermeture, l'ouverture d'une JFrame (et j'en passe) mais pas un plantage puisque ce n'est pas considéré comme un event (encore heureux déjà qu'avec les exceptions les gens font nawak).

Oui ... c'est gênant ...
Et si l'on écrivait au fur et à mesure mais en lançant l'écriture dans un nouveau Thread ...
Ou simplement que le Thread indépendant écrit les résultat tout les x temps ?
Quand un programme plante, c'est uniquement dans le Thread où il y a eu le pb je pense ...

Aussi, es-ce qu'un thread infini même en pause mage aussi des ressources ...
Je n'oublie pas ordonnancateur ... donc même en pause, en Thread ne ralentit-il pas ?

le système le plus bête pour logger une erreur:

main {
   try {
   application.run();
   } catch (Throwable t) {
      Ouvrir stream fichier.
      écrire t.
      Fermer stream fichier/
   }

}

Le soucis d'utiliser un Thread c'est surtout qu'en cas de plantage du Thread principal tu perds la main sur l'autre Thread... et à la limite il vaut mieux rester ignare sur la cause du plantage plutôt que d'avoir des threads qui se balandent (pour ça en tout cas).

et la méthode de shakhal fonctionne mais franchement c'est déguelasse

D'accord ...
ça me dérange d'ouvrir un flux à chaque fois quand même, les flux sont réputé assez lourds non ?

Citation : Maximus48

et la méthode de shakhal fonctionne mais franchement c'est déguelasse

Ca dépend du contexte, ici en effet c'est moche, mais on peut utiliser ça en complément d'un système de log efficace pour gérer les unhandled exceptions(notamment les NPE).

Ca vaut mieux qu'un crash silencieux de l'appli:

try {
    engine.start(true);
} catch (Exception e) {
    e.printStackTrace();
    JOptionPane.showMessageDialog(null, e.getMessage(),
                    "An unhandled error occured", JOptionPane.ERROR_MESSAGE);
}

Citation

D'accord ...
ça me dérange d'ouvrir un flux à chaque fois quand même, les flux sont réputé assez lourds non ?

Pourquoi à chaque fois, tu l'ouvres seulement si ca plante, et si ton app plante, le dernier de tes soucis c'est qu'un flux soit lourd.

Ça dépend de la fréquence de tes écritures. Personnellement, j'ai crée le même système en .NET et même en ouvrant-écrivant-fermant un fichier assez souvent (plusieurs fois par seconde) ca ne se sent absolument pas.
En plus si te ne veut logger que tes erreurs, ben elles ne sont pas sensées se produire en boucle dans ton programme. (edit : ou alors tu a des soucis bien plus graves que la lourdeur d'un flux à gérer... )

Euh quelque fois, je dois écrire des infos en boucle ...
Je pense que ce que je vais faire, c'est la possibilité de préciser si oui ou non je veux enregistrer tout de suite, et j'avise selon le cas.
donc par exemple si c'est en boucle, je stocke en mémoire vive, si c'est intéressant et pas en boucle, j'enregistre sur le champs ...
D'accord, je fais comme ça.
Merci bien.

oui tu peut très bien imaginer une méthode flush() qui enregistre ton cache dans le fichier de log. De cette façon tu peux appeler cette méthode quand ton cache atteint une certaine taille, mais également en l'appelant explicitement pour enregistrer des données sensibles.
Mais comme je te l'ai dis plus haut, même une écriture très fréquente ne perturbera pas l'exécution de ton programme.

D'accord, une dernière question, demander l'heure et la date au programme, es-ce que ça prend des ressources non négligeables ?

non.

Donc ça prend quelques ressources ...
D'accord, donc il va encore falloir mettre une condition pour mettre la date ou non ...
a force de conditions, ça vas alourdir encore !

Ah non, je sais, il faut simplement que je fasse plusieurs constructeur, comme ça pas de conditions et augmentation de la rentabilité ...

Au fait, le fait de faire plusieurs constructeurs sur une fonction souvent utilisé ne peut-il pas ralentir ?

Mais au bout d'un moment si tu veux faire quelque chose tu es bien obligé de prendre des ressources.
D'ailleurs je tiens à te rappeler le principe :
make it work
make it right
optimize later

Ne t'occupes pas de l'optimisation tant que ton programme n'est pas fonctionnel.

oui ...
Sauf que la, si je veux changer, j'ai déjà plusieurs centaine de System.out.println() à changer alors ...

Mais enfin, j'y pense, quand on ouvre une connexion à une base de donnée, le flux reste ouvert non ?
Si l'on fait ça dans une classe en static, on pourrait laisser le flux ouvert ...

Mais un flux ouvert prend peut-être des ressources ?

C'est assez incroyable : je vois des tas de posts sur des considérations bizarroïdes sur les logs et pas une seule mention de Log4j : http://logging.apache.org/log4j/1.2/

Tu mets ça dans ton projet, tu le configure et tu ne te pose plus aucune question. Énormément d'applis pros logguent avec ce système.
C'est presque toujours propre (à moins de vraiment faire le con avec) et ça gère les flux 1000x mieux que n'importe qui.

PS : En plus c'est plus souple, plus facile à désactiver / réactiver au besoin et il faut vraiment bourriner comme un malade pour voir un impact sur les perfs.

Citation : SpaceFox

C'est assez incroyable : je vois des tas de posts sur des considérations bizarroïdes sur les logs et pas une seule mention de Log4j : http://logging.apache.org/log4j/1.2/

Tu mets ça dans ton projet, tu le configure et tu ne te pose plus aucune question. Énormément d'applis pros logguent avec ce système.
C'est presque toujours propre (à moins de vraiment faire le con avec) et ça gère les flux 1000x mieux que n'importe qui.

PS : En plus c'est plus souple, plus facile à désactiver / réactiver au besoin et il faut vraiment bourriner comme un malade pour voir un impact sur les perfs.

y a l'api java logging, qui marche très bien aussi mais au stade où il en est,à essayer d'optimiser chaque instruction sans prendre en compte l'ensemble du programme, vaut mieux le laisser tâtonner je crois, ça lui sera plus profitable de mettre un peu les mains dans le cambouis pour comprendre comment ça marche vraiment une machine.

J'ai dit plus haut ce qui me gênait dans l'API Loggin, c'est qu'on ne peu pas lire aisément le fichier généré, c'est même pas du xml ...
Si vous savez comment lire facilement un fichier générer par loggin, je suis preneur.

Merci )à SpaceFox pour ce lien, je vais regarder ça.

Citation : Dominique0796

J'ai dit plus haut ce qui me gênait dans l'API Loggin, c'est qu'on ne peu pas lire aisément le fichier généré, c'est même pas du xml ...
Si vous savez comment lire facilement un fichier générer par loggin, je suis preneur.

Merci )à SpaceFox pour ce lien, je vais regarder ça.

si tu avais lu la doc de l'api loggin, tu verrais que ce n'est pas le cas.

Tu devrais vraiment apprendre à chercher un peu avant de poster chaque fois qu'un truc t'échappe, tu vas faire quoi le jour où tu auras un problème particulier que personne d'autre n'a eu?