Action automatique en début et fin de méthode

Bonjour,

J'aimerai savoir si quelqu'un connait un moyen en java d'automatiser différentes actions (l'appel d'une méthode statique, par exemple) au début et à la fin d'un grand nombre de méthodes.

En gros, j'ai une méthode statique (appelons-la Perso.log() ) qui génère des logs personnalisés et que je dois appeler en début et fin d'un tres grand nombre de méthodes dans mon application.
Au lieu de copier/coller les appels à Perso.log() dans toutes les méthodes de quasi toutes les classes de mon appli, je me demandais s'il était pas possible d'automatiser le processus, un peu sur le même principe que les OnLoad() et autres pour les composants graphiques (je comprend qu'il y a une enorme difference, mais c'est pour expliquer le concept).

Peut-être en utilisant des @annotations, ou en passant par une interface ou classe abstraite qui serait implémentée/héritée par toutes les classes dont je veux "logger" les méthodes ?

Si quelqu'un l'a déjà fait, ou a une idée qui pourrait marcher, je suis preneur!

Merci d'avance,

Nymethny.

http://ewawszczyk.developpez.com/tut...va/spring/aop/

Merci beaucoup pour cette réponse, je sais maintenant que ce que je veux faire est possible :D.
Je vais donc orienter mes recherches du coté de l'AOP.

J'ai tout de même une petite question (probablement stupide, mais... :oops: ) :
N'utilisant pas Spring, et n'étant pas particulièrement familier avec les différents framework, je ne suis pas sur d'avoir compris comment cela fonctionne réellement.
Vu que l' "ajout" de code se fait visiblement à la compilation, faut il obligatoirement utiliser un framework ?
Ou cela peut-il être géré uniquement par une/des librairie(s) à inclure dans le projet ?

Merci d'avance,

Nymethny.

Si tu utilises l'AOP Spring, alors il faut intégrer Spring (une lib). L'ajout des aspects se fait au runtime. D'ailleurs que dans le contexte Spring, c'est à dire pour les instances qui ont été créées par Spring.
Par contre il existe une autre manière de faire de l'AOP avec aspectJ pour laquelle le tissage (weaving), c'est à dire l'ajout des aspects, se fait à la compilation. Avantage: dans ce cas il n'y a pas la limitation sur les instances qui ont les aspects ou pas comme pour Spring. Inconvénient: c'est une phase de compilation particulière donc ton process de build doit être adapté.
Dans les deux cas tu introduis une dépendance runtime (aspectjrt.jar pour aspectJ, Spring+ses dépendances dans le cas AOP Spring).

Regarde plutôt du côté d'AspectJ:

http://www.eclipse.org/aspectj

Utiliser Spring et faire de l'AOP juste pour faire du logging, c'est gaché quand même. A la place d'avoir les appels dans le code il aura 4 km de fichier xml.
Tu seras content avec ton gros fichier xml.

Quel est le soucis de faire un appel a un logger partout dans ton code ?
C'est très classique et très utilisé.

Si tes méthodes font partie d'un contrat d'interface: -> dynamic Proxy
http://alain-defrance.developpez.com...cationhandler/ (juste le début et utiliser la forme la plus simple: voir la doc)

Je suis plutôt d'accord avec Jimmy, si l'application contient déjà Spring l'OAP Spring a son intérêt, maos ajouter Spring juste pour les logs c'est du lourd...d'autant plus qu'il y a des limitations (l'AOP ne marche que sur les Spring beans, mais les instances de la même classe qui ont été instanciées en dur n'auront pas les aspects).
A priori, aspectJ serait plus adapté dans ce cas là pour avoir automatiquement les logs sur toutes les méthodes respectant un certain pattern.
[edit]après vérif les dynamic proxies ont pour défaut d'être assez peu transparents...et ne marhent pas sur les instances normales, mais seulement sur les instances créées à l'aide des dynamic proxies (c'est d'ailleursd un des tehcniques sous-jacentes à Spring[/edit]

Merci beaucoup pour toutes vos réponses.

Je n'ai malheureusement pas le temps de me plonger dedans pour le moment, j'ai une pile de taches plus urgentes à réaliser avant ... ^^'

Quoi qu'il en soit, vous m'avez donnés pas mal de pistes à explorer, je sais au moins ou chercher maintenant ;)

Merci a vous :ccool:

Nymethny.