Discussion :

[polter]

Bonjour,

j'initialise mon projet avec Spring.

J'ai cependant une question : comment initialiser une variable dans une classe utilitaire (contenant uniquement des méthodes statiques) du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public final Tools {
     /**
      * Injectée par Spring
     **/
     private static String path;
 
     private Tools(){
          //constructeur privé pour empecher l'instanciation
     }
 
     public static void setPath(String string){
          PATH = string;
     }
 
 
     public static void do(){
          //methode statique utlisant path
     }

tout fonctionne en instanciant via <bean> et Spring un objet Tools mais je ne trouve pas cela très propre.

en effet, Tools étant une classe statique, on ne devrait pas l'instancier (elle devrait même être definie abstract pour empecher vraiment l'instanciation).
de plus path devrait etre definie en final (c'est une constante). j'ai viré final pour pouvoir l'initialiser avec Spring.

ya-t-il une solution pour faire plus proprement (classe Tools abstraite, et PATH en constante...) ?

Merci

[polter]

personne n'a une idée ?

[thelvin]

Moi j'ai bien plusieurs idées :

- Un <bean> ça sert à créer un objet ou une fabrique d'objets. Pas à setter des propriétés statiques. Et un applicationContext.xml, ça sert à définir des beans.
Conclusion, c'est pas le bon outil. Un ServletContextListener qui s'occupe de régler ça, par exemple, serait sûrement plus adapté. Il pourrait lire l'info d'un fichier .properties.
Dans le même genre, créer un bean sans id, d'une classe qui implémente InitializingBean, et dans son afterPropertiesSet() s'occupe d'appeler la méthode statique. Au fond, ça existe peut-être, mais j'en ai pas trouvé dans la doc. C'est quand même pas top comme usage.

- Une méthode qui a besoin de configuration préalable pour fonctionner n'a pas à être statique. Elle doit être méthode membre d'une classe instanciée, la configuration étant faite à l'instanciation. L'instance doit être passée à tous ses utilisateurs.
Bon, c'est vrai qu'il y a des exceptions, comme la configuration du logging. Et elle est faite avec des ServletContextListener. Disons que applicationContext.xml n'est pas conçu pour ça, même si on peut imaginer des cas où il s'agit d'injecter des dépendances.

[Patriarch24]

Tools étant une classe statique

Moi je commencerais par me poser la question suivante : Tools est-elle une classe statique, si ses propriétés changent ?

Les beans créés via Spring sont par défaut des singletons, donc il n'en existe qu'une seule instance. Cela remplace avantageusement la classe statique.
D'ailleurs, le pattern Singleton remplace la classe statique dans de très nombreux cas (tous ?) sans Spring.

[polter]

Bonsoir,

voila la question static/singleton.

les proprietes statiques peuvent etre modifié dans l'évolution d'un programme...


bon pour resoudre, je transforme ma classe static en une classe normal, avec utilisation du singleton initialisé par spring.


je vais également regarder du coté du ServletContextListener.

merci

[polter]

Il pourrait lire l'info d'un fichier .properties.

les parametres en question sont bien tiré d'un fichier propertie et charge par Spring via propertyPlaceholder

[thelvin]

les proprietes statiques peuvent etre modifié dans l'évolution d'un programme...

... Mais ne doivent pas l'être.

[polter]

... Mais ne doivent pas l'être.

et pourquoi pas ? Les propriétés statiques (non finales) seront ainsi modifiées pour toutes les instances de cette classe.

enfin bref, ca n'est pas le propos ici.

Mes classes utilitaires utilisent un paramètre situé dans un fichier properties. C'est la que j'ai besoin de les initialiser. ensuite il est vrai queces parametres ne sont pas modifiés durant l'utilisation de mon appli.

[thelvin]

et pourquoi pas ?

Parce que ça produit ce qui t'arrive là.
C'est un sujet très vaste, notamment c'est générateur de bugs graves si le changement s'opère en contexte multithread, toujours le cas avec les applis web.

Les propriétés statiques (non finales) seront ainsi modifiées pour toutes les instances de cette classe.

C'est juste une variable globale. Mais non-constante. De l'anti-objet, ce qui risque de se payer. Tu es d'ailleurs en train de le faire.

enfin bref, ca n'est pas le propos ici.

Je t'ai déjà donné des solutions. ServletContextListener, ou InitializingBean sans id qui sert juste à appeler tes méthodes statiques dans son afterPropertiesSet().

[polter]

C'est juste une variable globale. Mais non-constante. De l'anti-objet, ce qui risque de se payer. Tu es d'ailleurs en train de le faire.

justement, il n'y a pas d'objet ici puisque classe utilitaire (-> static)

Je t'ai déjà donné des solutions. ServletContextListener

on sort du context spring. donc plus aucun interet a utiliser spring ici. on repart sur une gestion des porperties a l'ancienne.

InitializingBean sans id qui sert juste à appeler tes méthodes statiques dans son afterPropertiesSet().

pas fan, ca fait bricolage.

[thelvin]

justement, il n'y a pas d'objet ici puisque classe utilitaire (-> static)

Et c'est tout le problème.
D'ailleurs, les bugs graves de non-constance en environnement multithreadé, on s'en fiche ?

on sort du context spring. donc plus aucun interet a utiliser spring ici. on repart sur une gestion des porperties a l'ancienne.

Spring ne se limite pas aux ApplicationContext, et simplifie beaucoup la programmation de beaucoup de choses.
Mais en effet, ApplicationContext n'est pas l'outil adapté pour ça, comme je l'ai dit.

Comme je l'ai déjà indiqué, la configuration du logging, problème similaire par commodité, se fait avec un ServletContextListener. Fourni par Spring, s'appuyant sur des outils Spring.

pas fan, ca fait bricolage

L'idée de départ est un bricolage.

[polter]

Et c'est tout le problème.
D'ailleurs, les bugs graves de non-constance en environnement multithreadé, on s'en fiche ?

tu peux m'en dire plus stp ?

[thelvin]

Ben, en résumé, une variable qui peut être lue et écrite par plusieurs threads, sans synchronisation, c'est pas fiable.

On ne sait pas si la modification arrive avant, après, et le plus grave pendant lecture ou écriture par les autres threads.
Ça peut facilement la mettre dans un état incohérent, et planter les threads qui comptent dessus. Voire faire des choses différentes de ce que ça doit faire.

Ce n'est pas seulement un problème d'utilisation statique, remarque. La même chose est vraie avec un singleton. Mais en général la chose est mieux "maîtrisée," disons, quand on prend l'habitude d'utiliser un singleton. Notamment parce que d'habitude on s'arrange pour qu'il ne soit pas modifiable, et quand on change ça, on réfléchit aux questions de multithreading.

[polter]

je ne pense pas avoir ce probleme puisque mes "outils" sont initialisés au demarrage de mon appli et ne sont ensuite plus modifiés.

par contre, d'un autre coté de mon appli, j'ai bien reflechi à ce probleme de multithreading et normalement c'est béton !

[Patriarch24]

Pour faire simple, une classe utilitaire est :
- statique si ses propriétés sont constantes
- un singleton (éventuellement avec des synchronisations dans le cas de multithreading) sinon.

[polter]

bonjour,

ma classe a bien des propriétés constantes mais initialisé au demarrage (stockée dans un fichier properties). d'ou mon utilisation de spring et propertyPlaceholder (qui n'est peut etre pas judicieux).