Discussion :

[Logan Mauzaize]

J'ai pas lu l'article mais je trouve le débat intéressant

Le service loader est un OSGi light, qui doit correspondre largement aux besoins réelles de modularisation des applications. Avec quelques bonnes pratiques, on peut rapidement en faire un équivalent (sauf la restriction des accès aux packages mais franchement c'est plus une plaie qu'autre chose).

Concernant la dette technique, il suffira (conformément aux bonnes pratiques) d'abstraire la gestion de la modularisation et donc de limiter les dépendances du système de modularisation choisi à cette abstraction.

[le y@m's]

Je me suis mal exprimé, j'ai voulu faire (trop) court:
c'est la classe "ServiceLoader" qui est une implémentation unique et finale. donc on ne peut pas imaginer qu'un founisseur Tiers puisse l'étendre (String ou hibernate).

Et je comparais aux Log parce que le Logger java souffre du même problème, ce qui fait que les entreprises se tournent plus volontier vers slf4g et log4j.

Pour revenir à la classe ServiceLoader, si Sun avait simplement fourni une interface pour cette classe, on aurait pu imaginer intercaler un proxy, fournir une autre implémentation etc. tout comme slf4j est basé sur une interface, et permet de rebrancher d'autres logger log4j, on même un logger maison.

En fait je me pose cette question pour faire des choix techniques sur des projets d'entreprise: si on choisi ServiceLoader comme technologie de découplage, puis que finalement on décide de changer de technologie (dans quelques années), quel est l'impact sur tous les développement réalisés (est-ce qu'on parle de dette technique dans ce cas?)

D'accord je comprends mieux ce que tu veux dire. Effectivement le mécanisme de chargement des implémentations est figé pour le ServiceLoader, mais comme le dit très justement Nemek, il suffit d'abstraire la gestion de la modularisation.

Il faut garder à l'esprit que le jdk est une brique de base, on ne peut pas tout y mettre. Le fait que Sun propose une simple classe utilitaire et pas un framework complet est un choix, il y a des pours et des contres, mais je pense que ce n'est pas une mauvaise chose. Si on veut une gestion de la modularisation plus poussé on utilise un framework, ou on met en place sa propre architecture selon ses propres besoins .

[Logan Mauzaize]

Les prochaines version de Java devrait proposer un système de gestion des versions des librairies, à voir si ca ne se transforme pas en intégration d'OSGi ou d'une API "générique" comme pour XML.

Ca aurait été bien qu'ils proposent un jeu d'interface, le problème c'est comment définir la factory à utiliser ?_?

[lvr]

Question: je veux faire la même chose, mais une partie de mes services est distribuée dans mon application (dans l'exemple du codec: je distribue 2 codes dans mon codec et veut laisser la porte à des codecs-tiers).
Comment et où je déclare les services incorporés dans mon application ?

[le y@m's]

Question: je veux faire la même chose, mais une partie de mes services est distribuée dans mon application (dans l'exemple du codec: je distribue 2 codes dans mon codec et veut laisser la porte à des codecs-tiers).
Comment et où je déclare les services incorporés dans mon application ?

Je n'ai pas très bien compris ta question .
Dans l'exemple des codecs donné, pour ajouter des codecs tiers il suffit de rajouter un (ou plusieurs) jar(s) dans le classpath contenant (chacun) :

• Une (ou plusieurs) implémentation(s) tierce(s) du CodecSet.
• Un fichier META-INF/services/com.package.CodecSet contenant la liste des implémentations.

[lvr]

Mon jar de "base" vient avec 2 "codecs". Auquel d'autres "codecs" tiers peuvent être ajouté sous la forme de jar annexes. Chaque jar annexe contient un fichier META-INF/services/com.package.CodecSet.
La question est: que faire des "codecs" inclus dans le jar de base ? Incorporer dans ce jar un fichier META-INF/services/com.package.CodecSet avec une ligne par "codec" ?

Aujourd'hui j'ai fait simple:
- les codecs de base (que je connais): je les charge avec Class.forName("My_first_codec").
- les codecs tiers je les charge avec le ServiceLoader

[le y@m's]

Mon jar de "base" vient avec 2 "codecs". Auquel d'autres "codecs" tiers peuvent être ajouté sous la forme de jar annexes. Chaque jar annexe contient un fichier META-INF/services/com.package.CodecSet.
La question est: que faire des "codecs" inclus dans le jar de base ? Incorporer dans ce jar un fichier META-INF/services/com.package.CodecSet avec une ligne par "codec" ?

Oui c'est exactement ça, ainsi tu peux tout charger avec le ServiceLoader .

[lvr]

Merci. j'essaye ça.

[lvr]

Ok. Super et facile à mettre en oeuvre. Je craignais juste par rapport à l'instanciation, mais bon c'est passé...

[Mathieu Salles]

Bonjour,

Suite à une question que j'ai posé sur le forum (http://www.developpez.net/forums/d12...s/#post6645759) on ma redirigé sur cet article.

Cependant, je ne comprends pas tout sur le fonctionnement de cette classe et notamment je ne comprends pas la phrase :

Le ServiceLoader utilise un cache et un système d'initialisation à la demande. En effet, l'implémentation est instanciée lors de l'appel à la méthode next() de l'Iterator puis mise en cache. Ainsi, en itérant une deuxième fois, on récupère la même instance du service. Il est possible de vider le cache (et ainsi forcer la réinstanciation du service) en appelant la méthode reload() ou en créant un deuxième ServiceLoader avec ServiceLoader.load().

Plus précisément :

Ainsi, en itérant une deuxième fois, on récupère la même instance du service

Je garde quand même de bon espoir de pouvoir me servir de cette solution pour mon projet

Cordialement,
Mathieu

[Mathieu Salles]

Il est donc particulièrement indiqué pour le développement de plugin/modules (on peut facilement imaginer une interface Plugin dont on chargerait les instances avec le ServiceLoader).

Voila c'est exactement ça que je veux mais comment savoir ce que je dois mettre dans mon interface ?

Mathieu

[Logan Mauzaize]

Ce dont tu as besoin

La première chose c'est qu'une application et un plugin ont des cycles de vie. Alors commence par prévoir cette gestion dans ton interface :

Solution 1)

Code :

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

1
2
3
4
5
6
7
 
public interface MyPluginSolution1 {
  /**
   * Notifies plugin state changes.
   **/
  handlePluginLifeCycle(PluginLifeCycleEvent plce);
}

Solution 2)

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
20
21
 
public interface MyPluginSolution2 {
  /**
   * Plugin is loaded but not started, it shouldn't be used.
   **/
  loadPlugin(PluginLifeCycleEvent plce);
  /**
   * Plugin is started, it must be ready to use.
   * If not, the method must throw an exception.
   **/
  startPlugin(PluginLifeCycleEvent plce);
  /**
   * Plugin is stopped, it shouldn't be used anymore. Execution resources can be released (eg. clean cache).
   * Optionally, plugin stopping can be cancelled by throwing a VetoException.
   **/
  stopPlugin(PluginLifeCycleEvent plce);
  /**
   * Plugin is unloaded, all resources must be released.
   **/
  unloadPlugin(PluginLifeCycleEvent plce);
}

[Mathieu Salles]

Ok oui je vois l'idée générale cependant je ne voit pas bien à quoi correspond ton argument "plce".

Je suppose à mon objet plugin mais dans le doute je demande ^^

EDIT : Alors je viens de voir avec mon maître de stage et je me suis rendu compte que ma notion de plugin était erroné.

Pour moi finalement un plugin c'est "juste mettre un fichier dans un dossier". On ne va pas s'inquiéter de savoir si on peut déactiver, arrêter un plugin, c'est juste une manière de gagner en souplesse dans notre application (qui restera interne à l'entreprise)

[Logan Mauzaize]

Ok oui je vois l'idée générale cependant je ne voit pas bien à quoi correspond ton argument "plce".

"plce" vient du type de l'argument Plugin Life Cycle Event.

Pour moi finalement un plugin c'est "juste mettre un fichier dans un dossier". On ne va pas s'inquiéter de savoir si on peut déactiver, arrêter un plugin, c'est juste une manière de gagner en souplesse dans notre application (qui restera interne à l'entreprise)

Gérer un cycle de vie permet de se caler à celles de ton application (de manière générale) :

1. Lancement
2. Initialisation
3. Démarrage des services
4. Démarrage de l'IHM (éventuellement)

... Et l'arrêt en sens inverse.

Sinon ton interface doit juste fournir les informations dont peux avoir besoin l'application au sujet de ton plugin.

[Mathieu Salles]

Voilà en faite mon maitre de stage ma dit de pas faire une usine à gaz et de faire au plus simple donc aujourd'hui j'ai une interface comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
public interface IPlugin {
  public String GetName();
  public String GetInfoClient();
  public list<Object> Perimeter();
  public String AddClientUI();
  public String ReadClientUI();
  public string HomeMenuUI();
  public string ReadBillUI();
}

[Logan Mauzaize]

Voilà en faite mon maitre de stage ma dit de pas faire une usine à gaz et de faire au plus simple donc aujourd'hui j'ai une interface comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
public interface IPlugin {
  public String GetName();
  public String GetInfoClient();
  public list<Object> Perimeter();
  public String AddClientUI();
  public String ReadClientUI();
  public string HomeMenuUI();
  public string ReadBillUI();
}

Pour information, en Java et par convention, les noms des méthodes commencent par une minuscule et String prend une majuscule comme tous les types non primitifs.

[le y@m's]

Voilà en faite mon maitre de stage ma dit de pas faire une usine à gaz et de faire au plus simple donc aujourd'hui j'ai une interface comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
public interface IPlugin {
  public String GetName();
  public String GetInfoClient();
  public list<Object> Perimeter();
  public String AddClientUI();
  public String ReadClientUI();
  public string HomeMenuUI();
  public string ReadBillUI();
}

Donc il ne te reste "plus qu'à" écrire les différentes implémentations (les différents plugins).

Code :

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

1
2
3
public final class Plugin1 implements IPlugin {
   // ... code d'implémentation ici
}

Tu peux écrire autant d'implémentations (plugins) que tu veux, pour les lister il te suffit d'utiliser le ServiceLoader:

Code :

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

1
2
3
for(IPlugin plugin : ServiceLoader.load(IPlugin.class)) {
   // ...
}

Après il te reste à gérer le fait d'ajouter dynamiquement des plugins au classpath. Cela n'est pas couvert par le tuto mais tu peux par exemple utiliser un URLClassLoader pour charger des jars depuis un répertoire prédéfini. Fait une recherche sur le forum, il y a plusieurs sujets qui traitent de ça .


[HS]ce que je trouve moche les noms d'interface commençant par I [/HS]

[Mathieu Salles]

Oui voila il me reste plus qu'à faire ça ^^

Merci pour vos réponses et désolé pour les convention, j'ai pas trop fait attention