[Thread] Lancer la couche métier dans un thread dédié

Version imprimable

05/05/2009, 12h46
cheprod

[Thread] Lancer la couche métier dans un thread dédié

Bonjour à tous,

Je développe une application dont la partie présentation est assurée par Swing. La couché métier est accessible via un Singleton appelé Middleware. Ce singleton possède des méthodes du type newProject, recordProject, simulate, etc... appelées par la couche Swing (par exemple en faisant Middleware.getInstance().newProject()).

J'ai bien compris les problématiques d'exécution dans les threads qui vont bien (thread EDT pour les "actions" graphiques et thread dédié pour les "actions" métier en tache de fond). Je me suis également penché du coté de SwingWorker dispo depuis java 6. Je trouve tous cela élégant dans le cadre de simples petits exemples.

Pour une application de taille supérieur, (à moins que je sois passé à coté d'un truc énorme) je trouve ces mécanismes assez lourd à gérer notamment par le fait de devoir créer des threads ou d'implémenter des SwingWorkers de manière systèmatique. Je me vois par exemple mal implémenté un SwingWorker par tâche de fond que j'ai à effectuer... surtout qu'ils doivent embarquer du code métier si je veux par exemple gérer des Progress Bar.

Je me posais donc la question de savoir s'il existait un moyen de faire exécuter automatiquement toutes les méthodes du Singleton Middleware dans un thread dédié (par exemple en le lanceant d'une manière spécifique) ?

Merci d'avance pour votre aide ;)
06/05/2009, 16h58
gifffftane

Je pense que tu peux y arriver par le biais des aspects avec spring, par exemple. Mais il faut springuifier ton appli, ce n'est pas forcément un mal. (mais vérifie que j'ai pas dit de bêtises avant).

Sinon, coté swing, tu as la notion d'Action, censée factoriser les... actions ; l'intention est bonne, mais je trouve pas toujours pratique la mise en oeuvre.

Perso je lance un thread ou un SwingWorker par tâche de fond à lancer ; vu les problèmes de synchro que ça pose, je ne suis même pas sûr que ce soit gérable de façon générique ?...

Bonjour,

Merci pour ces quelques pistes. En ayant creuser pas mal aujourd'hui je me rend compte que faire quelques choses de générique n'est pas forcément gagner et dans tous les cas, je serais obligé dans le code métier de faire remonter l'information sur l'état d'avancement de la tache.

En ce qui concerne Spring, je comptais pas vraiment l'utiliser pour le moment... je sais que je devrais me pencher dessus un jour ou l'autre mais difficile de tout faire en même temps.

En fait j'utilise le "Swing Application Framework" défini dans la JSR 296 et qui je trouve simplifie pas mal la vie même s'il pourrait être amélioré (Je crois que son intégration est prévu dans Java 7).

J'ai donc pensé à me concocté un mini-framework pour faire ce dont j'ai besoin.

Le framework se compose des classes suivantes :

Une interface que doivent implémenter les composants graphiques permettant de montrer l'état d'avancement:

Code:

1
2
3
public interface ProgressListener {
	public void setProgress(Integer value);
}

Une interface que doit implémenter la classe que va appeler le métier pour informer de sa progression

Code:

1
2
3
public interface WorkerInterface {
	public void setWorkProgress(Integer value);
}

Une classe abstraite AbstractSwingWorker que vont étendre mes SwingWorker:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public abstract class AbstractSwingWorker extends SwingWorker<Integer, String> {
 
	protected List<ProgressListener> listProgressListener;
 
	public AbstractSwingWorker() {
 
		super();
		listProgressListener = new ArrayList<ProgressListener>();
 
		/* On ajoute le listener sur la proprieté "progress" */
		addPropertyChangeListener(new PropertyChangeListener() {
			public void propertyChange(PropertyChangeEvent evt) {
				if ("progress".equals(evt.getPropertyName())) {
					for (Iterator<ProgressListener> iterator = listProgressListener.iterator(); iterator.hasNext();) {
						ProgressListener progressListener = iterator.next();
						progressListener.setProgress((Integer) evt.getNewValue());
					}
				}
			}
		});
 
	}
 
	/**
         * 
         * @param progressListener
         */
	public void addProgressListener(ProgressListener progressListener) {
		listProgressListener.add(progressListener);
	}
 
	/**
         * 
         * @param progressListener
         */
	public void removeProgressListener(ProgressListener progressListener) {
		listProgressListener.remove(progressListener);
	}
 
}

Un exemple d'extension :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
public class SwingWorkerOpenProject extends AbstractSwingWorker implements WorkerInterface {
 
    /**
     * 
     */
    private File file;
 
    /**
     * 
     */
    private MyFrame myFrame;
 
	/**
         * @param myFrame 
         * @param file 
         * 
         */
	public SwingWorkerOpenProject(MyFrame myFrame, File file) {
		super();
		this.myFrame = myFrame;
		this.file = file;
	}
 
	@Override
	protected Integer doInBackground() throws Exception {
		Middleware.getInstance().openProject(file, this);
		return 0;
	}
 
	@Override
	protected void process(List<String> strings) {
		// A implementer
	}
 
	@Override
	protected void done() {
		try {
			/* Le traitement est terminé. */
			setProgress(100);
			/*
			 * À la fin du traitement, affichage dans myFrame de l'interface
			 */
			this.myFrame.finishOpenProject();
 
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
 
	@Override
	public void setWorkProgress(Integer value) {
		this.setProgress(value);
	}
 
}

Dans le code de appelant (la classe MyFrame), j'ai donc défini 2 méthodes : une méthode exécuté lors du clique par exemple sur un bouton et une autre une fois que le métier c'est exécuté :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Action public void openProject() {
 
		JFileChooser jfc = new JFileChooser();
		jfc.setCurrentDirectory(new File("." + File.separator + "project"));
 
		int resultat = jfc.showOpenDialog(this.getMainFrame());
		if (resultat == JFileChooser.APPROVE_OPTION) {
 
			File file = jfc.getSelectedFile();
 
			JDialogProgress jDialogProgress = new JDialogProgress();
 
			SwingWorkerOpenProject swingWorkerOpenProject = new SwingWorkerOpenProject(this, file);
			swingWorkerOpenProject.addProgressListener(jDialogProgress);
			swingWorkerOpenProject.execute();
            }
}

Code:

1
2
3
public void finishOpenProject() {	
	// Action d'affichage	
}

La classe JDialogProgress qui implémente l'interface ProgressListener :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public class JDialogProgress extends JDialog implements ProgressListener {
 
	/**
         * 
         */
	private static final long serialVersionUID = 4960191407679629756L;
 
	/**
         * 
         */
	JProgressBar jProgressBar = new JProgressBar();
 
	/**
         * 
         */
	public JDialogProgress() {
 
		Container container = this.getContentPane();
		container.add(jProgressBar);
 
		container.validate();
		container.repaint();
 
		this.setSize(300, 50);
		this.setVisible(true);
 
	}
 
	public void setProgress(Integer value) {
 
		jProgressBar.setValue(value);
 
	}
 
}

Et pour terminer la méthode openProject de la classe Middleware :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/**
* Open the project from a file
* @param file 
* @param workerInterface
*/
public void openProject(File file, WorkerInterface workerInterface) {
 
	//---
	workerInterface.setWorkProgress(10);
	try {
                Thread.sleep(1000);
        } catch(InterruptedException e) {
                e.printStackTrace();
        }
 
	File fileBin = new File(file.getParent()+File.separator+"bin");
	ClassLoader classLoader = this.loadClasses(fileBin);
 
	//---
	workerInterface.setWorkProgress(20);
	try {
                Thread.sleep(1000);
        } catch(InterruptedException e) {
                e.printStackTrace();
         }
 
	//etc...
 
}

Avis et commentaire bienvenus ;)

On verra demain pour le paufinage...

06/05/2009, 21h58
tchize_

pour spring et les aspect. C'est sur que c'est puissant (possibilité de rajouter dynamiquement des surcouche de code sur des appel de méthode (comme par exemple lancer un thread :p)) mais j'éviterais de jouer avec ca sans avoir au préalable une connaissance approfondie du java. Par ce que, avec la programmation aspect, le programme peut se retrouver a faire totalement autre chose que ce que dit le code, et c'est pas facile à digérer pour le programmeur :D
06/05/2009, 22h44
gifffftane

Pour ProgressListener, attention que un listener est censé étendre l'interface EventListener ; ok, ça ne sert absolument à rien, ni de près ni de loin, ok avec un nom pareil on ne sait pas si c'est un event ou si c'est un listener, mais c'est quelque part dans la spec des javabeans, comprenne qui pourra.

Mais en fait je ne suis pas sûr à te lire que ton ProgressListener soit un listener au sens java bean ?

Méfie toi qu'utiliser sleep pour pauser un thread c'est courir au devant des ennuis si c'est dans l'edt.

Pour ce qui concerne le Swing Application Framework, j'avais regardé au début, et cela m'avait paru... complètement nul. Spring propose une bien meilleure, bien que différente, approche pour la notion d'application, me semble-t-il et sous toute réserve bien sûr et avec tout le respect que je dois à tous.

Et merci à tchize_ pour ses précisions : j'avais parlé sans vraiment connaître, et c'est toujours un plaisir d'avoir raison sur les choses qu'on connait pas.
06/05/2009, 23h11
cheprod

Merci pour ces quelques précisions.

@tchize_ : Je ne connaissais absolument pas ces aspects là de Spring. Il faudra que je m'y penche car cela à l'air d'être intéressant. J'avais juste utilisé l'outil pour codé un pattern MVC au niveau application mais finalement j'avais abandonnée l'idée car j'avais du mal à créer une application flexible.

@gifffftane : Pour le ProgressListener, le nom doit être mal choisi :D c'est juste un composant graphique qui doit être capable d'afficher l'état de la progression. Rien à voir donc avec un EventListener ou autre chose mais il faudrait que je regarde la spec java bean pour voir ce qu'il y a d'écrit dedans à ce sujet.

Pour les sleeps, justement ils ne sont pas dans l'edt mais dans un autre thread créer automatiquement lors de l'appel à la méthode doInBackground du SwingWorker.

Et pour le Swing Application Framework, en effet, il n'y a pas grand chose dedans (à moins que je sois passé à coté de grosses choses) mais ça facilite un peu certaines opérations redondantes. Heu... d'ailleurs en ressortant ce lien, je viens de voir qu'il y avait quelque chose pour la gestion des taches longues... je verrais tous ça demain...

Encore merci ;)