il semble que votre citation finale arrive trop tôt. Cela devrait être après le dernier paramètre.
Cette astuce a fonctionné pour moi.
J'ai remarqué quelque chose d'intéressant: lorsque je lance mon application en utilisant la ligne de commande suivante:
java -Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Si j'essaie de me connecter à ce port à partir d'une machine distante à l'aide de jconsole, la connexion TCP réussit, certaines données sont échangées entre jconsole distant et l'agent jmx local où mon MBean est déployé, puis jconsole affiche un message d'erreur de connexion. J'ai effectué une capture WireShark, et cela montre l'échange de données provenant à la fois de l'agent et de jconsole.
Ainsi, ce n'est pas un problème de réseau, si j'effectue un netstat -an avec ou sans la propriété système java.rmi.server.hostname, j'ai les liaisons suivantes:
TCP 0.0.0.0:9999 0.0.0.0:0 LISTENING
TCP [::]:9999 [::]:0 LISTENING
Cela signifie que dans les deux cas, le socket créé sur le port 9999 accepte les connexions de n'importe quel hôte sur n'importe quelle adresse.
Je pense que le contenu de cette propriété système est utilisé quelque part lors de la connexion et comparé à l'adresse IP réelle utilisée par l'agent pour communiquer avec jconsole. Et si ces adresses ne correspondent pas, la connexion échoue.
Je n'ai pas eu ce problème lors de la connexion depuis le même hôte en utilisant jconsole, uniquement à partir de vrais hôtes physiques distants. Donc, je suppose que cette vérification n'est effectuée que lorsque la connexion vient de «l'extérieur».