thread avec return dans une boucle

Version imprimable

16/05/2008, 09h41
Tanebisse

thread avec return dans une boucle
Bonjour,
J'ai une classe java Toto qui étends la classe Thread, dans mon appli (Web JEE),
je créé un objet Toto, après avoir fait un Toto.start(), je créé une boucle while qui test si mon thread est tjrs actif et dans laquelle j'appelle une méthode de Toto qui me renvoie une valeur. Ex :
Code:

1 2 3 4 5 while(toto.isAlive()){ maValeur = toto.calculValeur(); return maValeur; }
Mon soucis, c'est qu'une fois que j'ai fait le return, je suis sorti de ma boucle while, hors je voudrais continuer à appeler calculValeur car la valeur change régulièrement (c'est un écouteur de port). Comment puis-je faire ?

utilise la technique du listener.
Tu donnes un objet à ton Thread. Un peu de code sera plus facile à comprendre :

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 interface Ecouteur
{
  public void newValue( int value );
}
 
public class EcouteurImpl implements Ecouteur
{
  public void newValue( int value )
  {
    ...je fais ce que je veux de "value"...
  }
}
 
public class MonThread implements Runnable
{
  private Ecouteur ecouteur;
 
  public MonThread( Ecouteur e )
  {
    ...
    ecouteur = e;
    ...
  }
 
  public void run()
  {
    ...
    while( bidule )
    {
      ...
      ecouteur.newValue( calculNewValue );
      ...
    }
  }
}

16/05/2008, 10h30
Tanebisse

Ok, je vais essayer, ça va me permettre de voir si j'ai bien compris. Par contre quel est l'intérêt de passer par une interface pour ecouteur ?

Le problème c'est que la méthode que tu appelles "calculNewValue()", c'est pas une méthode qu'on appelle c'est une méthode qui réagit à des évènements c'est l'implémentation serialEvent de l'interface SerialPortEventListener.
16/05/2008, 10h44
dinobogan

Citation:

Envoyé par Tanebisse

Par contre quel est l'intérêt de passer par une interface pour ecouteur ?

Le Thread n'a pas à connaitre la classe qui implémente l'interface. Il n'a pas à savoir que c'est une classe à toi, ou à Tartampion. Ca permet de faire du code réutilisable, évite d'utiliser des méthodes non permises dans le thread. On s'assure ainsi que le thread ne pourra utiliser que les méthodes de l'interface.

Citation:

Envoyé par Tanebisse

Le problème c'est que la méthode que tu appelles "calculNewValue()", c'est pas une méthode qu'on appelle c'est une méthode qui réagit à des évènements c'est l'implémentation serialEvent de l'interface SerialPortEventListener.

Peu importe. L'appel à "newValue" peut se faire n'importe ou dans ton thread. J'ai fait un "calculNewValue" juste pour l'exemple.
Si tu n'y arrives pas, donne le code qui te pose problème.

Code de la classe Ecouteur

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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
 
public class EcouteurCom implements SerialPortEventListener {
 
	private CommPortIdentifier portId;
 
	private SerialPort serialPort;
 
	private BufferedReader fluxLecture;
 
	private ActionForward action;
 
 
 
	/**
         *
         */
	public EcouteurCom() {
		// TODO Auto-generated constructor stub
	}
 
 
	/**
         * @param name
         */
	public EcouteurCom(String port) {
 
		// initialisation du driver
		Win32Driver w32Driver = new Win32Driver();
		w32Driver.initialize();
		// récupération de l'identifiant du port
		try {
			portId = CommPortIdentifier.getPortIdentifier(port);
		} catch (NoSuchPortException e) {
		}
		// ouverture du port
		try {
			serialPort = (SerialPort) portId.open("EcouteurCom", 2000);
		} catch (PortInUseException e) {
		}
		// récupération du flux
		try {
			fluxLecture = new BufferedReader(new InputStreamReader(serialPort
					.getInputStream()));
		} catch (IOException e) {
			e.printStackTrace();
		}
		// ajout du listener
		try {
			serialPort.addEventListener(this);
		} catch (TooManyListenersException e) {
		}
		// paramétrage du port
		serialPort.notifyOnDataAvailable(true);
		try {
			serialPort.setSerialPortParams(9600, SerialPort.DATABITS_7,
					SerialPort.STOPBITS_1, SerialPort.PARITY_EVEN);
		} catch (UnsupportedCommOperationException e) {
		}
		System.out.println("port ouvert, attente de lecture");
	}
 
 
 
	/*
	 * (non-Javadoc)
	 *
	 * @see javax.comm.SerialPortEventListener#serialEvent(javax.comm.SerialPortEvent)
	 */
	public void serialEvent(SerialPortEvent event) {
		// gestion des événements sur le port :
		// on ne fait rien sauf quand les données sont disponibles
		switch (event.getEventType()) {
			case SerialPortEvent.BI:
			case SerialPortEvent.OE:
			case SerialPortEvent.FE:
			case SerialPortEvent.PE:
			case SerialPortEvent.CD:
			case SerialPortEvent.CTS:
			case SerialPortEvent.DSR:
			case SerialPortEvent.RI:
			case SerialPortEvent.OUTPUT_BUFFER_EMPTY:
				break;
			case SerialPortEvent.DATA_AVAILABLE:
				String codeBarre = new String();
				try {
					// lecture du buffer et affichage
					codeBarre = (String) fluxLecture.readLine();
					System.out.println(codeBarre);
					String[] tabCodes = codeBarre.split(";");
 
					if(tabCodes.length >= 2){
						String numProg = tabCodes[0];
						String numSeq = tabCodes[1];
						//TODO tester si le programme et la séquence existe
						this.action = new ActionForward("/accueil.do");
						this.action.setProperty("numProg", numProg);
						this.action.setProperty("numSeq", numSeq);
 
					}
				} catch (IOException e) {
				}
				break;
		}
	}
 
 
 
	/**
         * @return the action
         */
	public ActionForward getAction() {
		return action;
	}
 
 
	/**
         * @param action the action to set
         */
	public void setAction(ActionForward action) {
		this.action = action;
	}
 
}

Code du Thread

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
 
public class EcouteurThread extends Thread {
 
	private boolean running;
	private EcouteurCom ecouteur;
 
	public EcouteurThread(EcouteurCom ec) {
		this.ecouteur = ec;
	}
 
	// Méthode appelé quand on fait thread.start
	public void run() {
		running = true;
		while (running) {
			try {
				Thread.sleep(2000);
 
			} catch (InterruptedException e) {
			}
		}
	}
 
	/**
         * Permet l'arrêt du thread
         */
	public void stopThread() {
		running = false;
	}
 
}

Ce que je voudrais récupérer c'est la propriété action de la classe EcouteurCom. En fait je dév avec Struts 1.3.8 et je suis dans une classe action quand je fais le "new EcouteurThread(ecouteurCom)". Ce que je veux au final c'est pouvoir modifier ma JSP en fonction des évènement d'ecouteurCom.

Je dois ajouter quoi à la méthode run ?

16/05/2008, 11h22
dinobogan

La classe qui génère l'événement appelle une méthode de l'interface.
Qui génère l'événement ? EcouteurCom.
Il faut donc transmettre un Ecouteur au constructeur de EcouteurCom.
La confusion vient du fait que dans mon exemple, celui qui génère l'événement est le thread, contrairement à ton appli.
16/05/2008, 11h27
Tanebisse

L'évènement se déclenche quand des données entre dans le port Com ecouté. Ça se fait tout seul. C'est bien le problème. Ou alors il faudrait peut-être que je test toute les 2s si la valeur de la propriété action à changer et en fonction réagir.
16/05/2008, 11h37
dinobogan

Citation:

Envoyé par Tanebisse

L'évènement se déclenche quand des données entre dans le port Com ecouté. Ça se fait tout seul. C'est bien le problème. Ou alors il faudrait peut-être que je test toute les 2s si la valeur de la propriété action à changer et en fonction réagir.

Et non, ce n'est pas le problème, mais la solution ;)
Dans l'exemple de code que je t'es fournit, il te suffit simplement de remplacer la classe "MonThread" par "EcouteurCom", et la méthode "run" par "serialEvent".
Il faut fournir un objet "Ecouteur" en paramètre du constructeur de "EcouteurCom". Dans la méthode "serialEvent", tu vas appeler "ecouteur.newValue".
Ta classe EcouteurThread ne sert à rien, puisque c'est EcouteurCom qui va se charger de générer des événements à chaque nouvelle lecture sur le port.
16/05/2008, 11h47
Tanebisse

Il faut quand même que ma classe EcouteurCom implemente Runnable ?
Et du coup quel type d'objet est Ecouteur ?
Je ne maitrise pas bien la notion de Thread.
16/05/2008, 11h56
dinobogan

Citation:

Envoyé par Tanebisse

Il faut quand même que ma classe EcouteurCom implemente Runnable ?
Et du coup quel type d'objet est Ecouteur ?

Non, l'API se débrouille pour écouter les infos transmises sur le port. Lorsque des infos arrivent, la méthode "serialEvent" est appelée. Inutile d'implementer Runnable. Le mieux est que tu fasses un test minimaliste, qui se borne à afficher en sortie standard ce qui est transmis à la méthode "serialEvent". Envoi des données sur le port, et tu verras ;)
Le type de l'objet Ecouteur, et bien..... c'est toi qui choisie :mrgreen:
La classe qui va implémenter "Ecouteur" devra être capable d'interpréter les données envoyées via sa méthode "newValue". Soit "serialEvent" envoie les données brutes dans "newValue", soit il commence une interprétation, soit.... à toi de penser ton architecture comme bon te semble.
Bon courage ;)
16/05/2008, 13h34
Tanebisse

Si j'ai bien compris, ma classe EcouteurCom je la laisse telquel, et l'objet que tu appelles dans ton exemple "ecouteur" ça peut être mon objet "action" et ta méthode newValue() correspond à ma méthode setAction().
16/05/2008, 14h21
dinobogan

Citation:

Envoyé par Tanebisse

Si j'ai bien compris, ma classe EcouteurCom je la laisse telquel, et l'objet que tu appelles dans ton exemple "ecouteur" ça peut être mon objet "action" et ta méthode newValue() correspond à ma méthode setAction().

L'objet "action" est un simple "conteneur". Il ne peut lui même rien faire de sa propre initiative. Lorsqu'un événement survient via "serialEvent", il faut bien avertir un objet capable de faire une vraie action ?
Que cherches-tu à faire lorsque tu lis de nouvelles données sur le port ?
16/05/2008, 14h49
Tanebisse

Quand je lis de nouvelles données sur le port je veux que ça change le contenu de ma page Web, en fait que ça change d'abord les propriétés numProg et numSeq et qu'en fonction je rafraichi ma page avec le contenu correspondant.
Je crois avoir trouvé une piste avec ThreadLocal, en gros il faut que mon ecouteur de port COm tourne en permanence et que je puisse accéder à ses propriétés constamment. Je vais donc faire un refresh regulier de ma page qui va donc aller dans mon action qui va vérifer que l'ecouteur de com existe ou non s'il existe je regarde ses propriétés numProg et num Seq si elles ont changé alors je recharge la page sinon je ne fais rien.
16/05/2008, 15h43
Tanebisse

Est-ce que tu sais comment mettre un thread en session ? Ou une technique équivalente ?
16/05/2008, 16h34
dinobogan

Citation:

Envoyé par Tanebisse

Quand je lis de nouvelles données sur le port je veux que ça change le contenu de ma page Web, en fait que ça change d'abord les propriétés numProg et numSeq et qu'en fonction je rafraichi ma page avec le contenu correspondant.
Je crois avoir trouvé une piste avec ThreadLocal, en gros il faut que mon ecouteur de port COm tourne en permanence et que je puisse accéder à ses propriétés constamment. Je vais donc faire un refresh regulier de ma page qui va donc aller dans mon action qui va vérifer que l'ecouteur de com existe ou non s'il existe je regarde ses propriétés numProg et num Seq si elles ont changé alors je recharge la page sinon je ne fais rien.

Non, EcouteurCom se suffit à lui même, inutile de mettre un ThreadLocal.
Je liste les étapes, dis moi si je me trompe :
1. EcouteurCom est lancé une fois pour toute par le serveur. Comme il écoute une ressource système unique, il faudrait en faire un singleton pour s'assurer qu'à tout moment il n'y a qu'une seule instance.
2. Un client se connecte.
3. La page du client se rafraichit régulièrement.
4. Lors d'un rafraichissement, le serveur va chercher l'instance unique de "EcouteurCom", et lui demande son objet "Action". Si l'action a changé, alors le serveur renvoit une nouvelle page, sinon rien.

Le singleton est important, car comment se comporte le serveur s'il y a plusieurs clients ? Il ne faudrait pas mettre plusieurs EcouteurCom sur un même port...

Du coup, toute l'histoire précédente avec les listeners est complètement inutile. Ton Thread sera "émulé" par le rafraichissement automatique de la page cliente. Le serveur fait le lien entre la demande cliente et "EcouteurCom". Il n'y a rien à mettre en session, car l'instance de EcouteurCom est unique.
Le seul léger soucis potentiel facilement réglable est sur les données partagées : il ne faudrait pas utiliser "action" pendant qu'il est modifié dans "serialEvent".
16/05/2008, 16h55
Tanebisse

Enfin j'ai trouvé la solution, en fait j'ai repris ma classe ecouteurCom initial qui héritait de Thread et qui implémentait SerialPortEventListener, tout ce que je fais c'est mettre cet objet en session s'il n'existe pas puis je test si ses propriétés ont changé si oui je modifie la page sinon je ne fais rien. Et je fais un reload régulier de la page.

Par rapport à ton dernier message tu dis :
-

Citation:

Il n'y a rien à mettre en session, car l'instance de EcouteurCom est unique

Mais si je ne le met pas en session comment je le récupère dans mon action Struts ?
-

Citation:

EcouteurCom est lancé une fois pour toute par le serveur.

l'objet EcouteurCom est créé dans mon action la première fois que je lance ma page web donc une sule fois oui mais ce n'est pas le serveur qui le créé de manière indépendante.
16/05/2008, 17h03
dinobogan

Citation:

Envoyé par Tanebisse

Par rapport à ton dernier message tu dis :
- Mais si je ne le met pas en session comment je le récupère dans mon action Struts ?
- l'objet EcouteurCom est créé dans mon action la première fois que je lance ma page web donc une sule fois oui mais ce n'est pas le serveur qui le créé de manière indépendante.

Justement, c'est un singleton. Il possède une méthode statique pour récupérer une instance unique.
ensuite, un EcouteurCom par utilisateur, est-ce vraiment nécessaire ? Sachant que toutes les instances d'EcouteurCom vont écouter le même port série. Donc une instance unique pour tout le serveur, et il devient inutile de construire une instance EcouteurCom et la placer en session.
Maintenant, si ton code fonctionne bien et que tu en es content, alors c'est suffisant ;)
16/05/2008, 17h09
Tanebisse

Je ne maitrise pas bien la notion de singleton, je ne vois toujours pas comment je peux accéder à mon objet EcouteurCom autre ment que par ma session, peux-tu me donner un exemple ?

Citation:

Envoyé par Tanebisse

Je ne maitrise pas bien la notion de singleton, je ne vois toujours pas comment je peux accéder à mon objet EcouteurCom autre ment que par ma session, peux-tu me donner un exemple ?

Exemple simpliste :
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 public class EcouteurCom { private EcouteurCom instance = new EcouteurCom(); private EcouteurCom() {} public static getInstance() { return instance; } public void blabla() { ... } } public class Blabla { ... public void uneMEthode() { EcouteurCom.getInstance().blabla(); } }
L'instance de EcouteurCom est donc unique. Bien sur, si le constructeur EcouteurCom peut générer des exceptions, alors il faut construire l'instance dans "getInstance" et synchroniser la méthode. Mais je te laisse lire les nombreuses pages dans les milliards de tutoriaux pour plus d'infos.

19/05/2008, 17h42
Tanebisse

OK je vais essayer ça.