Communication entre différents Jar's/Classloaders

Question

J'ai le problème suivant à résoudre :

Il y a deux jar des fichiers. Ces jar's démarrent indépendamment les uns des autres.

Maintenant, disons que la première jarre A.jar calcule ou calcule quelque chose et doit transmettre les résultats à la Commission européenne. B.jar .

J'ai essayé de communiquer via un Singleton central (Singleton enum et Singleton qui utilise un propre classloader comme mentionné ici : Classe singleton avec plusieurs chargeurs de classe différents ).

Mais ça n'a pas semblé fonctionner pour moi. Lorsque je lance les deux jar's, les hashcode des instances sont différents.

Quelqu'un peut-il me dire ce que je fais mal ? Ou d'autres idées pour résoudre mon problème ?

Answer 1

Il y a deux fichiers jar. Ces jar's démarrent indépendamment l'un de l'autre l'un de l'autre.

Donc ils sont séparés processus . Ils ne partageront pas les instances des classes, les variables, etc. Vous avez besoin d'une forme de communication interprocessus pour communiquer entre eux.

Il s'agit normalement d'une forme de protocole réseau (par exemple, les sockets TCP/UDP, HTTP, etc.). Vous pouvez également faire quelque chose de très simple comme lire/écrire un fichier partagé (ce n'est pas particulièrement agréable, mais c'est simple pour les cas simples).

Answer 2

Si vous exécutez 2 fichiers jar séparément, alors chaque fichier jar exécute sa propre instance JVM et rien n'est partagé entre eux. Il s'agit de deux processus distincts. Arrêt complet.

Si vous souhaitez communiquer entre eux, voici des alternatives : Cela dépend du type de données que vous souhaitez transférer.

Si ce n'est que des cordes, alors : si number of process = 2 et si vous en êtes sûr, alors stdin &8 stdout est la meilleure façon d'avancer. Un processus peut commencer à exécuter un autre Jar en créant un fichier Process en utilisant ProcessBuilder et ensuite utiliser les flux pour communiquer. L'autre processus peut simplement faire System.out pour transférer le message. Ceci est préférable à Socket, car vous n'avez pas à gérer la fermeture gracieuse de la socket, etc. (En cas d'échec et si le port n'est pas délié avec succès, cela peut être un gros problème).

si number of jar files > 2 (c'est-à-dire le nombre total de processus) et less than dites 10 vous pouvez probablement utiliser des sockets et communiquer par le biais de ces derniers. Cela devrait bien fonctionner, bien qu'un effort supplémentaire soit nécessaire pour gérer les sockets de manière élégante.

si number of process es Large entonces JMS devrait être utilisé. Il fait beaucoup de choses que vous n'avez pas besoin de gérer. C'est une tâche trop importante si le nombre de processus est moindre.

Dans votre cas, la procédure est donc la meilleure solution. Si les données que vous souhaitez transférer, peuvent même être des Objets. RMI peut être utilisé si le nombre de processus est inférieur. S'il y en a plus, il faut utiliser JMS encore.

Edit : Maintenant, pour tout ce qui précède, il y a beaucoup de travail sale impliqué. Pour changer, si vous cherchez quelque chose de nouveau et d'excitant, je vous conseille akka. C'est un modèle basé sur les acteurs qui communiquent entre eux en utilisant des messages. La beauté de la chose est que les acteurs peuvent être sur la même JVM ou sur une autre (très peu de configuration) et akka s'occupe du reste pour vous. Je n'ai pas vu de manière plus propre de faire cela :)