admettons que j'ai une méthode du style
 

 
Comment, au sein de cette méthode, je peux récupérer son nom ?
 
g bien vu les méthodes de class, mais ca retourne un array of methods, et va chopper la bonne au milieu...
 
C pour du logging en fait, g fait une class log qui utilise un loggeur...pour le moment ca marche très bien hormi que toutes les entrées dans la console proviennent de Util.log (ma classe), et que je voudrais personnaliser ça. Y'a un méthode  

 
Comment renseigner sourceMethod et sourceClass autrement qu'en les écrivant à la main lors de l'appel au loggueur ?

Peut-être utiliser la pile d'appel (si on peut, j'en sais rien en fait) ...

en fait mon problème devient plus précis au fur et à mesure que je bidouille :  
 

 
Ca ca marche (en gros ca récupère des paramètres de ligne de commande pour connaitre le niveau de verbosité).
 
Petit hic : je sais pas comment changer le handler (qui par défaut est ConsoleHandler), ni le formatter. Si j'en rajoute un, ca m'en fait 2, et tt les logs sont en double, et c'est le bordel. Quant au formatter, je sais pas sur quel handler le mettre vu que je ne sais pas comment s'appelle l'instance de ConsoleHandler créee par défaut...
 
Je demande ca parce que j'ai une petite classe de formater qui réduit les entrées à une ligne par entrée...contre 2 avec le formater actuel...

pour faire ce genre de trucs, l'aop est tout indiqué. c'est d'ailleurs probablement l'exemple que prennent la plupart des tutos.
(et tu seras bien content de faire ça en aop, le jour ou tu te rendras compte que ça sert à rien et que ça bloate ton code. ou plutot non, pour t'en rendre compte, continue par le faire à la barbare)

tu fais pêter une exception, tu regardes la tronche de la frame la plus haute de la pile et hop tu as le nom de la méthode.
 
tu mets l'exception à la poubelle et tu continues.

(classieux, le mec il veut juste logger du debug hein... doit pas encore savoir se servir d'un debugger)

ou va chercher l'information où on la trouve ...

well, avec de l'aop tu l'as de maniere plus propre et legere. (modification du bytecode, dynamiquement ou pas)
et la vraie question c'est de savoir si on a vraiment besoin de cette info

hum, je crois que je v m'en passer
 
--> et oui le débugger j'apprends...c foutrement pratique, on met des petits points dans la marge, on met des propriétés, et hop, ca s'arrete où on veut et ca dit ce que contient la var...ca t'intercepte les exceptions, et ca te dit tt les fois où sont les lignes qui merdent...c super pratique (je pense découvrir la roue, mais c pas grave, ca me fait plaisir)
 
--> sinon je trouve ca crade de lacher des erreurs dans le vide...enfin bon, mon pb se situe plus maintenant au niveau du Logger, et de la façon de virer le handler sur la console par défaut par ex...je me suis tapé tt la javadoc liée (Logger, LogManager, Level, Handler et dérivés, etc...
 
Mon pb c vraiment ca : l'output par défaut sur la console est super verbeux (2 lignes pour la moindre info), et surtout j'ai pas trouvé comment customizer les couleurs...
 
--> -- : c quoi AOP ? g trouvé "aspect-oriented programming", mais en quoi ca m'aide ? je veux juste pouvoir afficher mes infos de debug avec une granularité fine et réglée par avance, pour les philos de devel g pas le niveau encore...

mais ton truc de log c'est une librairie ou un truc maison??
emploie log4j
 
oui l'aop c'est bien aspect oriented programming.
pour ton cas particulier ça t'aide parce que tu peux mettre ton code de logging en dehors de tes classes business, et décider au runtime (par config par exemple) ou à la compil si tu inclus ces logs ou pas. avec l'aop tu peux  definir un "aspect" qui est executé par exemple pour tout appel de methode commençant par pouet, pour toute classe du package xyz, ce genre de conneries.

heu RTFM ???
 
Depuis la 1.4, java dispose d'une API de logging qui rend inutile toutes les autres développées avant...elle est super modulaire, compatible J2EE et gestionnaire de sécu...
 
http://java.sun.com/j2se/1.4.2/doc [...] ogger.html
 
le pb vient du handler par défaut...en fait ce logger n'a pas de constructeur utilisable...par un procédé zarb, tu appelles un loggeur avec un nom donné : si le logger existe, il t'es retourné, sinon il est créé...et si il est créé, il l'est avec un Handler par défaut, et un Formatter par défaut lié au Handler...et mon pb c que le Handler par défaut c la console, et que je peux rajouter un autre Handler, mais pas enlever celui-ci...et bien sur rien dans le java tutorial

je me disais aussi que ça ressemblait à log4j ton truc. forcément ils ont tout pompé
pour tout ce qui est handler et formatter, tu devrais pas avoir à t'en occuper par code. c'est de la configuration. je connais pas le systeme de log du jdk1.4 mais ça ressemble tres fortement à log4j, donc...

oui il me semble avoir lu que ct très inspiré de log4j...
 
je voudrais pouvoir modifier la couleur du flux qui sort sur la console (primo) et secondo pouvoir ajouter mon handler personnalisé qui met les logs sur une ligne (et qui marche), mais mon pb actuel c que les 2 handlers cohabitent (ce qui est normal en fait), mais j'arrive pas à virer le ConsoleHandler par défaut...donc tt mes logs sont en double, c qui est laid...

c'est de la config, rien d'autre.
pour ton handler personnalisé, je suis pas sur non plus que ça soit necessaire.

moi je suis sur que si : il gère un timestamp raccourci, et un layout sur une ligne...
 
-->tt le pb vient aussi du fait que autant un handler que je j'appelle je sais le configurer, parce que g son instance sous le nez, autant celui par défaut je suis dans la merde j'ai rien pour le configurer, g pas d'instance sur quoi pointer...

roh bordel.
t'as pas a *coder* le truc, c'est une histoire de fichier de config!

non c crade par fichiers de config : ca implique de modifier le fichier de conf qui se trouve dans le rep de java...c pas super propre je suis désolé...y'a tt les méthodes pour le faire dans l'API, et g trouvé d'ailleurs...je persiste à dire que c un domaine peu exploré par les tutos, et que c tt sauf clair (la plupart disent qu'en ajoutant un handler ca fait une sortie console d'une seule ligne, c faux, les infos remontant par défaut jusqu'au root Logger, si on désactive rien y'a tjs au moins une sortie sur le handler concerné, plus celle sur le root Logger...
 
--> g trouvé la cause de mon bug : le Logger fait remonter à tt sa hierarchie le log, et donc au root Logger, qui a par défaut une sortie console...faut que je vire la remontée de log pour ne plus l'avoir

t'es con ou quoi? le log c'est un truc qui doit etre configurable au runtime par le end user. tu crois qu'il a envie de se taper tes logs de debug en 400 couleurs?
peut etre qu'il aura envie de rien logger sauf les erreurs et de les recevoir par mail.... c'est à ça que sert le framework.  
si c'est juste pour écrire dans un fichier, tu te fais un FileWriter hein

c prévu dans mon appli, y'a des flags au lancement du programme...selon ce que tu mets, t'a 3 niveaux de debug...
 
et je persiste à trouver ca dangereux de laisser le fichier de conf tt décider : si le mec l'a bidouillé pour tester en laissé dans un état bizarre (genre logguer que ce qui est critical ou au contraire Finest, ben le soft aura un comportement pourri, et t'y peut plus rien...
 
--> pour la couleur : c mort, à moins de passer par JNI en faisant une merde pas portable pour un sous basé sur une DLL, y'a aucun moyen de changer la couleur de la console...c pas grave, ct pas le plus important
 
--> les logs c pour mon usage principalement, cad pour le codeur (dans mon cas ici)...l'appli va générer ses propres logs d'utilisation, dont la granulosité sera réglable dans les préférences