C’est peut-être une question bête, mais je ne trouve pas comment créer de logs spécifiques pour une action lancée par Crontab. J’aimerais les retrouver dans cet onglet lié aux jobs de mon Crontab.
puis dans la méthode asynchrone, appeler AppLog.log sur l’événement dédié (et pas les INFO, ERROR… de base).
par exemple :
AppLog.log("DEMO_ERR", Truc.class, "myMethod",
new String[] { "texte pour [1]", "texte pour [2]" ... },
null, grant);
Note: la jointure avec le job de la cron se fait tout seul via le thread qui l’exécute. Il n’y a normalement rien à faire. Sinon tu peux aussi récupérer l’UID si tu veux le loguer ailleurs.
Merci pour ces indications, mon job crée bien une ligne de Log mais elle n’est pas attachée au thread. Je n’arrive pas à implémenter ta proposition pour ce cas, j’ai tenté ceci mais je pense que c’est complètement tiré par les cheveux ? Et en plus ça ne marche pas
J’ai aussi une question supplémentaire, si je souhaite plutôt créer un fichier de log, est-ce que je dois le faire moi-même avec un objet spécifique, ou est-ce que je peux utiliser une fonctionnalité du socle ?
Le thread lancé par la cron est suffixé par le job UID, CronJob.getJobUid permet de l’extraire
Ce thread invoke la méthode qui doit simplement faire des AppLog.log
Tu peux voir les threads depuis le monitoring (si la tache est assez longue, sinon ajoute des sleep)
Attention, le bouton “Force immediate execution of task” depuis la UI Cron ne lance pas de job, la tache s’exécute dans le thread de servlet. Donc ici le lien ne se fera pas si le lancement est manuel ou par bouton. On va voir pour lancer un job pour garder la même mécanique.
Pour créer tes propres logs, tu peux configurer ton propre appender Log4j2 si ça reste technique, ou écrire dans un fichier lié à un champ document d’un objet métier pour qu’un utilisateur puisse les consulter…
Bref tout dépend de l’usage des logs une fois produits : consultation, purge…
La purge est déjà prévue dans le paramétrage de la cron (champ jobs depth).
Ok je reproduis le problème, en fait log_job_id est la FK, et l’UID est un champ ramené.
on va corriger.
UPDATE
Voilà ce sera corrigé en 5.3.62, mettre l’UID dans la clé étrangère ne pouvait pas marcher.
Impossible car le résultat de l’action est remonté au front de façon synchrone.
Le placer dans un Thread changerait ce fonctionnement, les logs seront juste en base et non liés à un job dans ce cas.