Discussion :

[Yopsolo33]

Bonjour

je souhaiterai "remonter" la pile d'exécution afin de récupérer la valeur d'un paramètre lors de l'appel d'une méthode précédente.
or par la stackTrace (Thread.currentThread().getStackTrace()[0]), je ne peux récupérer que le nom de la classe, le nom de la méthode voire le numéro de ligne au format chaine.

Mais pas les valeurs des paramètres.

Quelqu'un aurait-il une idée? Car ces valeurs existent bien dans la jvm...encore faut-ils qu'elles soient accessibles

Merci

[thelvin]

Infaisable avec une JVM normale.

D'ailleurs, ce n'est pas propre. Si tu veux que le paramètre soit dispo plus loin dans la pile d'appels, passe-le dans toute la pile, c'est tout.

(Note : je comprends assez mal la programmation orientée aspect. Il est possible que ceci offre une autre manière de le faire que de passer le paramètre à chaque appel.)

[tchize_]

ouais mais bon, meme avec des aspect ca reste déclaratif (au niveau de aspect mais déclaratif quand même).

Le seul cas ou c'est possible d'aller récupérer cette info, c'est quand le thread est mis en pause par un breakpoint via un debugger externe.

Donc oui, à passer ou stocker quelque part.

[oneagaindoguys]

Tu peux utiliser le débogger de ton EDI

[Yopsolo33]

Merci pour vos réponses.

Malheureusement passer ce paramètre tout le long n'est pas possible;

Pour préciser mon besoin, c'est une appli J2EE avec webservice d'un coté et BDD de l'autre.
Dans l'application, on génère un identifiant unique par appel au webservice.

Ce que je cherche à faire, c'est enrichir les logs lancés par Hibernate/Spring/cxf afin de visualiser cet identifiant dans la trace (j'utilise log4J pour tracer).

Ma première idée a été d'étendre la classe d'org.apache.log4j.WriterAppender ou plutôt celui du org.apache.log4j.PatternLayout, en récupérant dans la pile, la valeur de cet identifiant (qui est présent dans tous les beans passés en paramètre).

Innocemment, je ne pensais pas que ce serait si compliqué. Comment fait le debugger de mon EDI (Eclipse en l'occurrence) pour avoir accès à ces valeurs? Si lui peut les voir, on doit pouvoir y accéder, non?
J'étais persuadé qu'il existait une classe/méthode dans le package java qui permettait ce genre de chose mais dont je ne connaissais pas l'existence...

Si vous avez une autre idée, je suis aussi preneur

[JoeChip]

Il suffit de passer, lors de l'initialisation du log ou après, cet identifiant à la classe qui logge, aucun besoin de faire un truc aussi tordu que d'aller chercher dans la pile ; d'autant que cette pile toute complète avec les n° de ligne et tout n'existe que si le compilateur est mis en mode "debug" ; quand ce n'est pas le cas, ou pire, que le code est obfusqué, ça ne marchera peut-être pas aussi bien, je ne sais pas s'il y a des garanties là-dessus, en tout cas.

[Yopsolo33]

Je n'ai pas accès à l'initialisation du log vu que cette initialisation se fait dans les classes Hibernate/cxf/Spring.
A moins que je n'ai pas saisi ce que tu voulais dire...

[JoeChip]

Mais euh, tu ne peux pas faire une sous-classe ?

[tchize_]

log4j a déjà un mécanisme pour associer des informations supplémentaire de ce style, c'est le mapped diagnostic contexts. tu y stoke une valeur jusqu'à suppression, et tu demande au logs de l'afficher.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MDC.put("userId", userId);
try{
// appels à divers trucs
} finally {
    MDC.clear("userId");
}

et dans ta pattern, par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

%d %-5p [%c] (%X{userId}) %m%n

[Yopsolo33]

et ben voilà, c'est exactement mon besoin.

Merci de m'avoir rafraichi la mémoire...vu que je l'avais déjà utilisé dans d'autres applications ...

comment ne pas y avoir repensé plus tôt ^^

Merci encore