[Quartz] Passer paramètres à partir d'un job [Résolu]

[Rhodo33]

Bonjour, J'utilise Quartz pour planifier des tâches. La doc explique comment passer des paramètres vers les jobs, mais je recherche le moyen de faire passer des infos en sens inverse.
Quel serait le moyen le plus simple de passer des paramètres d'un job vers l'objet qui a planifié les jobs SVP ?

[tchize_]

Pas vraiment possible puisque l'objet qui a planifié le job n'existe plus depuis longtemps quand le job s'exécute

Si tu veux persiter ou interagir avec des données dans ton job, il faut le faire là où sont les données, en général dans une base de donnée.

[Rhodo33]

Merci pour ces infos.

En fait, je peux m'arranger pour que l'objet qui planifie vive le temps qu'il faut, disons pendant quelques jours. J'utilise une instruction du type

... Thread.sleep(TEMPS_DE_VEILLE);...

Il serait bien qu'il puisse consulter de temps à autre une info du type "C'est fait" ou bien "Il faut tout recommencer".

Puis-je utiliser un objet qui recueillerait les quelques infos dont j'aurais besoin ? je pense à l'interface JobListener :

public class MyJobListener implements JobListener...

Cet objet mis en forme serait-il lisible par l'objet qui planifie ? (Ou mieux pourrait-il envoyer l'info directement à l'objet qui planifie ?)

[tchize_]

Quartz ne gère pas la transmission de données. Toute ce qui va vers le job est stockée dans la DB comme propriété du job. Du fait de ce stockage, impossible de transmettre des objet complexes. Si tu veux que ton Job informe quoi que ce soit, c'est en dehors de l'api Quartz. Tu peux utiliser un JobListener, mais tu va être notifié de tous les jobs, pas seulement celui là.

Tu job peux stocker l'info sur son état d'avancement dans une base de données, ce serait plus sur. Un objet qui attends sur un Thread.sleep -> ca ne survis pas à un arrêt de l'application. Or quand on utilise quartz, c'est justement pour avoir la garantie que les job s'exécutent.

[fxrobin]

peut-être une question bête étant donné que je ne l'ai jamais fait avec Quartz, mais si ta classe "appelante" implémente "JobListener", alors il te suffit de l'ajouter à ton Job qui l'appelera à la fin de son travail.

C'est ni plus ni moins que le design pattern "Observer / Observable". C'est aussi comme cela que fonctionnent les SwingWorker en Swing ou encore les Callable / Future avec les Executor : http://blog.zenika.com/index.php?pos...nte-Java-1sur2

Ce n'est qu'une simple idée (à creuser) étant donnée que je ne l'ai jamais fait avec Quartz, comme indiqué au début de ma réponse.

Peut-être un exemple ici :
http://www.mkyong.com/java/quartz-joblistener-example/

[tchize_]

fxrobin: à quartz on ne passe pas des instances mais des noms de classes, c'est là toute la difficulté. En effet, un nom de classe ça peux se stoker dans une DB, une instance c'est plus difficile

[Rhodo33]

Merci à tous les deux,

Je vais voir cela :

" alors il te suffit (d'ajouter l'interface) à ton Job qui l'appelera à la fin de son travail."

J'économise un objet par rapport à ce que j'avais pensé. C'est déjà ça !

Mais j'ai une inquiétude concernant la philosophie de Quartz . Je lance mon exécution à partir d'Eclipse. Si j'interromps l'exécution, il ne me semble pas voir de threads tourner tout seuls (en ghosts). Mes logs me l'auraient dit.

Corrigez-moi si je me trompe ?

[tchize_]

Ben quand ton appli s'arrête quartz s'arrête, c'est normal.

[fxrobin]

Envoyé par tchize_

fxrobin: à quartz on ne passe pas des instances mais des noms de classes, c'est là toute la difficulté. En effet, un nom de classe ça peux se stoker dans une DB, une instance c'est plus difficile

regarde l'exemple de "mkyong", il le fait bien lui pourtant.

[tchize_]

Envoyé par fxrobin

regarde l'exemple de "mkyong", il le fait bien lui pourtant.

Au temps pour moi, c'est le "passer au Job" qui m'a confus
Oui, les listeners, c'est des instances, mais du coup t'as le problème inverse, c'est que les listeners, eux, tu les perds à l'arrêt :/

[fxrobin]

Sauf si le Listener est aussi l'appelant ... non ?

Ou alors il y a un truc que tu voies et qui m'échappe, mais pour moi c'est exactement comme en Swing avec les SwingWorker (voire les ActionListener) : on ne perd aucune instance, on est juste dans un Thread différent (quand c'est bien fait).

non ?

[Rhodo33]

Merci à tous les deux.

J'ai modifié l'exemple fourni par http://www.mkyong.com/java/quartz-joblistener-example/.

J'ajoute un getMessage à HelloJobListener. Ce getter est renseigné par ex. lors de la fin du job et il est lisible par l'objet qui lancé les jobs (soit ici CronTriggerExample ):

Thread.sleep(10000);
System.out.println("Message obtained: " + myJobListener.getMessage());

Dans mon cas personnel, cela suffit. J'obtiens un flag qui m'indique si un job est terminé ou non, quelle erreur est apparue.
Ce n'est pas un rapport complet, mais c'est déjà bien.

Encore merci.

[tchize_]

Envoyé par fxrobin

Sauf si le Listener est aussi l'appelant ... non ?

Quartz est, normalement, utilisé pour scheduler des jobs de manière plus ou moins permanent. A chaue redémarrage de l'appli, quartz récupère les job en attente dans la BD, exécute ceux en retards, etc.

Par contre, il ne stocke pas les listener, à chaque démarrage de l'appli, il faut réenregistrer les listeners

[fxrobin]

Okay.
Ca doit être comme les @Schedule sur les EJB alors.

[Rhodo33]

Bonjour,

Juste quelques impressions:

1. Un job peut modifier des informations par context.getJobDetail().getJobDataMap() et peut les garder pour un prochain triggering
2. Si on passe par context.getMergedJobDataMap(), le job peut modifier les informations, mais je n'ai pas réussi à trouver comment les garder pour un prochain triggering
3. En fait j'ai l'impression que les deux moyens donnent deux objets distincts et ce qui se passe sur l'un n'est pas vu par l'autre
4. De plus, context.getJobDetail().getJobDataMap() correspondrait à ce que je veux... sauf que je ne vois pas comment l'objet qui a lancé le trigger peut aller le récupérer.

Si j'ai une autre idée, je vous en ferai part.