Bonjour à tous,

Je développe actuellement un outil qui permet de vérifier la bonne rédaction d'un fichier. Il y a plusieurs règles (102) à vérifier pour conclure si oui ou non le fichier est correct. Pour ce faire j'ai une classe mère "rule" et 102 autres classes qui extends de "rule" me permettant de définir chaque règle. Enfin, j'ai le programme principal, le "moteur" qui permet de vérifier une ou plusieurs règles par ligne en fonction de la ligne traitée.

Tout fonctionne très bien. MAIS! Je DOIS diviser ce .jar en deux: la partie "moteur.jar" qui ne sera pas modifiable (question de sécurité) et la partie "règle.jar" qui sera modifiable.

La partie "règle.jar" doit être modifiable car le but est qu'un utilisateur puisse ajouter ses propres règles en suivant le pattern des autres règles. Puis l'utilisateur aura plus qu'à compiler "regles.jar" et le "moteur.jar" pourra les prendre en compte.

Mon problème est donc que le "moteur.jar" contient "règle.jar" en tant que librairie. Alors si j'ajoute une règle, il faut recompiler "règle.jar" (jusque là OK), mais il faut aussi recompiler "moteur.jar" pour qu'il prenne en compte les modifications effectuées sur "règle.jar". Or je ne veux pas que les utilisateurs aient à recompiler "moteur.jar", d'où le titre de mon post "Actualiser une librairie" afin d'actualiser "règles.jar" à chaque execution afin que règle.jar" ne soit pas en "dur" dans le code.

J'espère avoir été assez clair...;)

Merci d'avance!!!!

Si tu as 2 jar différents, il ne devrait pas y avoir de problème.

He bien non. Car le "regle.jar" est buildé avec le "moteur.jar"... du coup toute modification apporté à "regle.jar" n'est pas pris en compte lorsque j'utilise "moteur.jar". C'est comme si il fallait que je recharge cette librairie de regle pendant l'execution.

Une idée?

A ta place, je ferais tout d'abord 1 projets java avec 2 parties:

• Rules-api (qui contiendrait par exemple une interface IRule avec les méthodes que les règles personnalisées doivent redéfinir)
• Engine (pour la logique de déclenchement des règles. Utilise rules-api)

Avec ce  projets, je créerais un premier jar -> file-checker-core.jar

Je crée un autre projet java "File checker default rules" dans lequels je définis X règles par défaut. Ce projet dépend évidement de file-checker-core.jar

Je créé un jar avec de projet -> file-checker-default-rules.jar

Tu fournis tes 2 jar (file-checker-core.jar et file-checker-default-rules.jar) à l'application cliente qui peut du coup créer ses propres règles.

Avec cette découpe, l'application cliente peut même se passer des règles par défaut si elle n'en a pas besoin.

-
Edité par max-om-93 30 juillet 2015 à 10:16:33

Merci pour ta réponse!

C'est à peu près ce que j'ai (deux JAR dont un pour le moteur + interface pour les regles "moteur.jar", et l'autre qui contient toutes les règles modifiables "regles.jar"). Mais mon soucis est seulement dans l'utilisation du JAR modifiable.

Je souhaite que mon moteur puisse charger/utiliser le JAR contenant les règles sachant que celui-ci (regles.jar) peut avoir été modifié entre deux execution par exemple. Or pour le moment il est définit en tant que librairie dans "moteur.jar" et est donc en dur dans ce dernier.

Ce que je souhaite c'est plus une notion de plugin que de librairie car "regle.jar" sera amené à être modifié assez souvent.

Avec ce que je te propose, tu n'a plus de dépendance de moteur vers règles!

Montre moi comment ton moteur va chercher toutes les règles qui se trouvent dans le jar. Je pense que le problème vient de là et d'une très mauvaise architecture.

Le code qui récupère les règles (dans moteur.jar):

LoaderRules load = new LoaderRules();
rulesLoader=load.getRulesLoader();

Et donc le code dans regles.jar qui permet au moteur de tout récupérer:

public class LoaderRules {

	private static ServiceLoader<Check_Rule> rulesLoader ;

		public LoaderRules(){
			rulesLoader = ServiceLoader.load(modelChecker.rulecheck.Check_Rule.class);
		}
		public ServiceLoader<Check_Rule> getRulesLoader() {
			return rulesLoader;
		}
}

C'est (très) possible que l'architecture ne soit pas au top , mais l'outil m'a été fourni avec ces bases et il est quasi terminé

Je ne vois pas comment toutes les classes correspondant à une règle sont chargées.

Vous utilisez quoi pour aller les chercher? Introspection, annotations?

Je récupère tout graçe au ServiceLoader.

J'ai donc la liste des règles disponibles dans le répertoire "META-INF/services". 

Puis le tout est mis dans la liste "rulesLoader" comme on le voit sur le post précédent.

private static ServiceLoader<Check_Rule> rulesLoader;

Pourrais-tu me montrer ce qu'il y a dans META-INF/services?

rules.check.Check_regle5
rules.check.Check_regle17
rules.check.Check_regle18
rules.check.Check_regle19
rules.check.Check_regle21
rules.check.Check_regle22
rules.check.Check_regle23
rules.check.Check_regle24
rules.check.Check_regle29
rules.check.Check_regle30
rules.check.Check_regle31
rules.check.Check_regle32
rules.check.Check_regle35
rules.check.Check_regle39
rules.check.Check_regle41
rules.check.Check_regle44
rules.check.Check_regle45
rules.check.Check_regle46
rules.check.Check_regle51
rules.check.Check_regle65
rules.check.Check_regle68
rules.check.Check_regle73
rules.check.Check_regle74
rules.check.Check_regle76
rules.check.Check_regle77
rules.check.Check_regle78
rules.check.Check_regle81
rules.check.Check_regle83
rules.check.Check_regle84
rules.check.Check_regle85
rules.check.Check_regle86
rules.check.Check_regle87
rules.check.Check_regle88
rules.check.Check_regle89
rules.check.Check_regle91
rules.check.Check_regle100
rules.check.Check_regle101
rules.check.Check_regle102
rules.check.Check_regle103
rules.check.Check_bug_56
rules.check.Check_bug_566
rules.check.Check_bug_59
rules.check.Check_bug_9
rules.check.Check_bug_1

L'utilisateur pourra modifier ce fichier (contenu dans "regle.jar") une fois qu'il aura crée sa propre règle, ce qui permettra au Java de prendre en compte les nouvelles règles que l'utilisateur aura codé.

D'accord.

Actuellement, pour compiler (Je en parle pas de l'exécution), est ce que moteur a besoin de regle? En d'autres termes, si tu enlèves la dépendance entre moteur et règle, est-ce-que moteur contient des erreurs de build?

Oui il a besoin de règle.

Du coup lisant ton post je me dis que c'est peut-être l'inverse que je devrai faire: regle qui a besoin de moteur?

Oui par exemple.

Si tu me donnes le code source de ton projet, je veux bien te montrer et t'expliquer comment j'aurais fait

Salut!!

J'ai finalement réussi à faire ce que je souhaitais faire. Comme je l'ai mentionné dans mon post précédent j'ai inversé l'architecture!!! Ce qui m'a pris pas mal de temps...

Avant j'avais moteur.jar qui utilisait regle.jar, mais comme regle.jar est amené à changer souvent, il fallait compiler regle.jar puis moteur.jar.

Maintenant j'ai regle.jar qui utilise moteur.jar ce qui est plus logique car moteur.jar n'est pas modifiable! Du coup l'utilisateur aura à recompiler regle.jar et c'est OK!!

Merci pour ta patience !!