Les Services Java

Bonjour,

Je viens d'écrire un petit article qui présente l'utilisation des services Java.
:arrow: http://ydisanto.developpez.com/tutoriels/java/services/

Bonne lecture.

le y@m's

La complexité (requiert un fichier de config externe) est difficile à justifier. Si mon interface se nomme IAuthenticate, je préfère que le module chargé de l'implémentation possède une factory AuthenticateFactory implémentant l'interface IAuthenticateFactory

Ensuite de quoi dans le code qui fait appel au module, j'ai quelque chose du genre

Code:

---

1 2	IAuthenticateFactory authFact = (IAuthenticateFactory) Class.forname("mon.package.ma.AuthenticateFactory").newInstance(); IAuthenticate aut = authFact.getAuthenticate();

---

Je vous fait grâce du traitement des exceptions que peut générer ce code. Ce code impose l'existence d'un factory de nom fixe dans le sous module, mais par contre il permet d'éviter d'avoir recours à un fichier de propriétés. Avec l'expérience, les fichiers de config en java font moins peur, mais pour les gens qui débutent, je me souviens que c'était pas de la tarte.


J'en viens à ma question: qu'apportent vraiment de plus les services java comparé à la méthode alternative que je viens de donner et qui permet a priori d'aboutir au même résultat?

Citation:

---

Envoyé par Aldian

J'en viens à ma question: qu'apportent vraiment de plus les services java comparé à la méthode alternative que je viens de donner et qui permet a priori d'aboutir au même résultat?

---

D'un point de vue organisation d'un projet, je trouve peu pratique d'imposer un nom de classe et donc de package. Si j'avais envie de sceller mon JAR, je serais alors obligé d'exclure la factory.

Avec la solution de la factory statique, tu es moins souple. Essaie d'imaginer la procédure à suivre pour remplacer ton implémentation par une autre, de préférence sans avoir à recompiler. C'est un point important car quand tu dois faire fonctionner ton logiciel et que tu n'es pas sur ton poste de travail, tu dois faire avec ce que tu as. Cela peut être très pratique de remplacer un module défaillant par un module prévu pour le debuggage.

Mais le point le plus important qui me vient à l'esprit et qui est évoqué dans l'article, c'est le fait de pouvoir avoir plusieurs implémentations de ton service. Pour t'en sortir avec la factory statique, il va falloir jongler avec les classloaders. Ce qui me semble plus difficile que d'utiliser un fichier de configuration.

@Aldian

Dans ton exemple tu es obligé de connaitre la classe d'implémentation.

Quand on utilise les fameux fichier META-INF/services, on ne présage aucune implémentation. C'est l'ajout d'un jar d'implémentation qui active le truc ...
D'ailleurs il me semble que le ServiceLoader ne se base pas uniquement sur les META-INF/services, et regarde également dans les System.properties.

C'est très utilisé par les API XML. C'est relativement rare d'avoir à implémenter ce genre de chose...

@Aldian

Comme vous le soulignez il est effectivement préférable d'utiliser une factory, je suis parfaitement d'accord avec vous et c'est d'ailleurs ce qui est dit dans la javadoc du ServiceLoader.
Mais je ne me suis volontairement pas attardé sur le coté "design" car je voulais un tutoriel simple qui se contentait de présenter la technologie.

L'avantage des services Java sur la méthode que vous présentez est tout simplement l'abstraction. Dans votre exemple le nom de l'implémentation (en tout cas de l'implémentation de la factory) est écrit en dur dans le code... votre code fait donc directement référence à l'implémentation, l'abstraction est perdue. Votre code revient à écrire

Code:

---

IAuthenticateFactory authFact = new AuthenticateFactor();

---

A la différence qu'il utilise la réflexion inutilement (je ne m'étendrais pas sur la mauvaise utilisation de la réflexion).
Si demain vous voulez changer l'implémentation de la factory vous êtes bon pour changer votre code (certes une seule petite ligne mais ça suffit), recompiler votre application et la réinstaller chez votre client.

C'est là qu'est la "justification" du fichier de déclaration qui sert juste à dire "hey, moi j'implémente telle interface" pour pouvoir être listé par le ServiceLoader. Typiquement vous placerez ce fichier dans un jar contenant votre implémentation et vous ajouterez ce jar au classpath de l'application. Ce qui ressemble assez fortement au concept de module/plugin vous en conviendrez.
Et je ne pense franchement pas que l'écriture de ce simple fichier ajoute une complexité faramineuse, au contraire je trouve ça assez mineur au vu du gain apporté.


[edit] grilled [/edit]

Citation:

---

Envoyé par bugsan

D'ailleurs il me semble que le ServiceLoader ne se base pas uniquement sur les META-INF/services, et regarde également dans les System.properties.

---

Le ServiceLoader utilise exclusivement les répertoires META-INF/services, il n'utilise jamais les System.properties ;).

Bonjour,

Merci pour cet exemple et cet article, cette fonction est intéressante, même si certains préfèrent les proxys ;)

j'ai relevé [ou plutôt : Eclipse n'a pas aimé...] un petit bug dans l'implémentation de Authenticator.java :
l'argument "password" de la méthode authenticate est déclaré comme String alors que la variable "password" issue du console.readPassword est de type tableau de char.
Comme l'implémentation de cette méthode dans StubAuthenticator a bien "password" en char[], je suppose que c'est dans l'interface qu'il y a une coquille...

Citation:

---

Envoyé par micromy

j'ai relevé [ou plutôt : Eclipse n'a pas aimé...] un petit bug dans l'implémentation de Authenticator.java :
l'argument "password" de la méthode authenticate est déclaré comme String alors que la variable "password" issue du console.readPassword est de type tableau de char.
Comme l'implémentation de cette méthode dans StubAuthenticator a bien "password" en char[], je suppose que c'est dans l'interface qu'il y a une coquille...

---

C'est corrigé ;) :merci: de l'avoir signalé.

Citation:

---

Envoyé par bugsan

@Aldian

Dans ton exemple tu es obligé de connaitre la classe d'implémentation.

---

Je pense que vous avez lu un petit peu trop vite. Mon implémentation ne pose aucun souci du point de vue du remplacement d'un module par un autre. La seule chose sur laquelle je m'engage, c'est sur le fait que tout module doit contenir un factory nommé AuthenticateFactory implémentant l'interface IAuthenticateFactory, qui est donc connue de la même manière que l'interface IAuthenticate est connue.


Mais à aucun moment, je n'ai besoin de connaitre l'implémentation concrête du factory. Je suis totalement libre de la changer d'un module à l'autre du moment que le nom est conservé et l'interface implémentée. Par conséquent vos objections concernant la perte de l'abstraction ne tiennent pas ;).


Merci pour les autres commentaires :)

Citation:

---

Envoyé par Aldian

Je pense que vous avez lu un petit peu trop vite. Mon implémentation ne pose aucun souci du point de vue du remplacement d'un module par un autre. La seule chose sur laquelle je m'engage, c'est sur le fait que tout module doit contenir un factory nommé AuthenticateFactory implémentant l'interface IAuthenticateFactory, qui est donc connue de la même manière que l'interface IAuthenticate est connue.

Mais à aucun moment, je n'ai besoin de connaitre l'implémentation concrête du factory. Je suis totalement libre de la changer d'un module à l'autre du moment que le nom est conservé et l'interface implémentée. Par conséquent vos objections concernant la perte de l'abstraction ne tiennent pas ;).

---

Et comment fais tu pour avoir plusieurs implémentations ? Tu écris X fois une Factory avec le même nom que tu mets dans chacun de tes jars ? Que va te donner un Class.forName() dans ce cas ? Comment vas tu récupérer toutes les implémentations ?
Ce que tu dis est peut être valable dans le cas où tu ne veux qu'une seule implémentation, mais pas si tu veux gérer une collection de plugins/modules (ce pour quoi est conçu le ServiceLoader).

Non je n'écris qu'un seul factory, mais lors de l'appel de la méthode IAuthenticate aut = authFact.getAuthenticate(); du factory, je passe en paramètre une string qui indique l'implémentation qui m'intéresse. Ce n'est donc pas un problème rédhibitoire non plus, mais je vois bien où tu veux en venir: ça introduit la nécessité de réécrire le factory chaque fois qu'on ajoute une possibilité d'implémentation. Merci de ta patience :).

Citation:

---

Envoyé par Aldian

Non je n'écris qu'un seul factory, mais lors de l'appel de la méthode IAuthenticate aut = authFact.getAuthenticate(); du factory, je passe en paramètre une string qui indique l'implémentation qui m'intéresse. Ce n'est donc pas un problème rédhibitoire non plus, mais je vois bien où tu veux en venir: ça introduit la nécessité de réécrire le factory chaque fois qu'on ajoute une possibilité d'implémentation. Merci de ta patience :).

---

Donc tu précises l'implémentation (via le String) lors de l'appel, on en revient à la perte d'abstraction non ? Si tu ajoutes une nouvelle implémentation tu dois modifier ton application pour y ajouter le nouveau String correspondant ?
Et pour récupérer l'ensemble des implémentations disponibles (par exemple pour lister les modules dispo pour ton application) comment gères tu le fait d'avoir plusieurs factory du même nom ? Tu jongles avec les classloaders comme l'a suggérer Deaf ?

Ah oui non en fait laisse tomber ma réponse précédente, j'avais mal compris l'objection.

Dans ma solution, a supposer que j'ai un projet ayant besoin d'une authentification, et de plusieurs modules implémentant cette authentification, je ne peux en plugger qu'un seul à la fois, et il va effectivement me falloir modifier le factory si je veux en changer. Ou alternativement chaque module peut avoir sa propre version du factory, mais dans ce cas de figure, impossible d'en mettre plus d'un à la fois dans le classpath.

Mais si jamais je venais à avoir besoin de services d'authentification de nature différentes à deux endroits distincts de l'application, je serai bloqué. Merci de tes explications, c'est plus clair maintenant :).

Oui le ServiceLoader est surtout adapté pour la gestion d'une collection de modules avec plusieurs implémentation simultanées et il est vrai que l'on a rarement besoin de plusieurs mécanismes d'authentifications.
Pour un exemple plus parlant voyons celui de la javadoc du ServiceLoader.
Imaginons que l'on développe une application qui utilise des codecs (video ou audio ou autre peu importe).
Soit deux interface Encoder et Decoder représentant les fonctionnalité d'encodage/décodage.
Soit une interface de type factory CodecSet déclarant les méthodes

Code:

---

1 2	Encoder getEncoder(String encodingName); Decoder getDecoder(String encodingName);

---

Le code utilisant le ServiceLoader pour récupérer un codec :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

private static ServiceLoader<CodecSet> codecSetLoader = ServiceLoader.load(CodecSet.class);   public static Encoder getEncoder(String encodingName) { for (CodecSet cp : codecSetLoader) { Encoder enc = cp.getEncoder(encodingName); if (enc != null) return enc; } return null; }   public static Decoder getDecoder(String encodingName) { for (CodecSet cp : codecSetLoader) { Decoder dec = cp.getDecoder(encodingName); if (dec != null) return dec; } return null; }

---

Code:

---

1 2 3 4 5

String codecName = ... // lecture du nom du codec de l'objet à décoder Decoder decoder = getDecoder(codecName) if(decoder == null) { throw new UnsupportedOperationException("codec non supporté : " + codecName); }

---

Maintenant on peut enrichir notre application avec le support de nouveaux codecs en simplement ajoutant des jars dans le classpath, chacun contenant une implementation de CodecSet (déclarée dans META-INF/services) qui fournira ces nouveaux codecs.

Je pense que cet exemple est peut être plus parlant ;).

Pour ma part je trouve qu'on se rapproche des concepts de service sous Java/OSGi sans pour autant être aussi flexible ni aussi puissant.
OSGi est adopté de plus en plus sur les serveurs d'applications (Jonas, Glassfish,...) et sans doute vous l'utiliser aussi sans le savoir : Eclipse (Equinoxe) est un framework OSGi.

Citation:

---

Envoyé par zolive

Pour ma part je trouve qu'on se rapproche des concepts de service sous Java/OSGi sans pour autant être aussi flexible ni aussi puissant.
OSGi est adopté de plus en plus sur les serveurs d'applications (Jonas, Glassfish,...) et sans doute vous l'utiliser aussi sans le savoir : Eclipse (Equinoxe) est un framework OSGi.

---

Le ServiceLoader est effectivement orienté service (pas pour rien qu'il s'appelle ServiceLoader :P) et on peut le rapprocher des concepts services d'OSGI.
Cependant ce sont deux choses très différentes et pas vraiment comparable.
OSGI est un framework complet qui défini le cycle de vie d'une application, un environnement d'exécution, des modules, une liste de services, etc.
Le ServiceLoader n'est lui qu'une simple classe qui gère le chargement d'implémentations d'une interface donnée avec une approche orientée service.
Alors c'est normal que le ServiceLoader ne soit pas aussi puissant qu'OSGI.

Oui en fait l'exemple de la javadoc est un peu abrupt:

Citation:

---

Suppose we have a service type com.example.CodecSet which is intended to represent sets of encoder/decoder pairs for some protocol

---

Ce genre de phrase est typique du gars qui fait ça tous les jours et qui n'imagine pas un seul instant que ses lecteurs puissent ne pas avoir l'habitude de ce type de problématique (ou alors c'est des touristes). La plupart des gens savent qu'il existe un concept nommé "codec" et que c'est lui qui est à blamer s'ils ne peuvent pas lire une vidéo. Quant à savoir ce que ça représente vraiement il y a un monde. Et du coup, l'exemple bateau de la doc n'est pas bateau, à part pour les devs habitués de la manipulation audio ou des protocoles.

Mais avec la discussion précédente, on comprend beaucoup mieux, merci :)

Intéressant, je ne connaissait pas et du coup, j'avais un peu recodé ma propre implem à la manière d'Aldian. :D

Les avantages que je vois :
-méthode standard intégrée au JDK

les inconvénients:
-une seule méthode de conf basée sur de fichiers, pas d'annotation, pas d'injection par programme, pas de parcours automatique de répertoire, façon plugin eclipse.
-une seule classe d'implementation final, (comme pour le Logger java), ce qui empêche d'utiliser d'autres implementations, notamment des framework guice etc.

En fait c'est le dernier inconvénient qui me ferais hésiter à utiliser cette techno.

Citation:

---

Envoyé par deltree

-une seule méthode de conf basée sur de fichiers, pas d'annotation, pas d'injection par programme, pas de parcours automatique de répertoire, façon plugin eclipse.

---

Même réponse que pour OSGI, le ServiceLoader est une simple classe et pas un framework complet, ce n'est pas vraiment comparable ;).

Citation:

---

Envoyé par deltree

-une seule classe d'implementation final, (comme pour le Logger java), ce qui empêche d'utiliser d'autres implementations, notamment des framework guice etc.

---

Soit tu n'as pas tout bien lu du tutoriel et des commentaires précédents soit je n'ai pas bien compris ce que tu voulais dire, mais il est tout à fait possible d'avoir et de déclarer plusieurs implémentations.

Code:

---

1 2 3 4 5 6

ServiceLoader<MyInterface> loader = ServiceLoader.load(MyInterface.class); List<MyInterface> implementationsList = new ArrayList<MyInterface>(); // on récupère toutes les implémentations déclarées for(MyInterface impl : loader) { implementationsList.add(impl); }

---

Citation:

---

Envoyé par le y@m's

Même réponse que pour OSGI, le ServiceLoader est une simple classe et pas un framework complet, ce n'est pas vraiment comparable ;).

---

-Oui c'est vrai et c'est beaucoup plus léger qu'embarquer un framework , c'est un avantage de plus.

Citation:

---

Envoyé par le y@m's

Soit tu n'as pas tout bien lu du tutoriel et des commentaires précédents soit je n'ai pas bien compris ce que tu voulais dire, mais il est tout à fait possible d'avoir et de déclarer plusieurs implémentations.

---

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?)

Enfin bref, je râle :D maisc'est un détail, le tuto est très bien et permet de comprendre rapidement l'intérêt du ServiceLoader.
Et merci pour tes réponses ;)

J'ai pas lu l'article :aie: 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.

Citation:

---

Envoyé par deltree

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 ;).

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 ?_?

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 ?

Citation:

---

Envoyé par 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 ?

---

Je n'ai pas très bien compris ta question :oops:.
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.

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

Citation:

---

Envoyé par 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" ?

---

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

Merci. j'essaye ça.

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

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 :

Citation:

---

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 :

Citation:

---

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

Citation:

---

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

Ce dont tu as besoin :aie:

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:

---

1 2 3 4 5 6 7

public interface MyPluginSolution1 { /**    * Notifies plugin state changes.    **/ handlePluginLifeCycle(PluginLifeCycleEvent plce); }

---

Solution 2)

Code:

---

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); }

---

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)

Citation:

---

Envoyé par Mathieu Salles

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.

Citation:

---

Envoyé par Mathieu Salles

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.

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:

---

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(); }

---

Citation:

---

Envoyé par 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:

---

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.

Citation:

---

Envoyé par 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:

---

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:

---

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:

---

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]

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 :aie: