wydaje się, że twój końcowy cytat pojawia się za wcześnie. Powinien znajdować się po ostatnim parametrze.
Ta sztuczka zadziałała na mnie.
Zauważyłem coś interesującego: kiedy uruchamiam moją aplikację za pomocą następującego wiersza poleceń:
java -Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Jeśli spróbuję połączyć się z tym portem ze zdalnej maszyny za pomocą jconsole, połączenie TCP powiedzie się, niektóre dane są wymieniane między zdalną konsolą jconsole i lokalnym agentem jmx, na którym jest wdrożony mój komponent MBean, a następnie jconsole wyświetla komunikat o błędzie połączenia. Wykonałem przechwytywanie wireshark i pokazuje wymianę danych pochodzącą zarówno z agenta, jak i jconsole.
Zatem nie jest to problem z siecią, jeśli wykonam netstat -an z właściwością systemową java.rmi.server.hostname lub bez niej, mam następujące powiązania:
TCP 0.0.0.0:9999 0.0.0.0:0 LISTENING
TCP [::]:9999 [::]:0 LISTENING
Oznacza to, że w obu przypadkach gniazdo utworzone na porcie 9999 akceptuje połączenia z dowolnego hosta pod dowolnym adresem.
Myślę, że zawartość tej właściwości systemowej jest używana gdzieś podczas połączenia i porównywana z rzeczywistym adresem IP używanym przez agenta do komunikacji z jconsole. A jeśli te adresy nie są zgodne, połączenie nie powiedzie się.
Nie miałem tego problemu podczas łączenia się z tego samego hosta za pomocą jconsole, tylko z prawdziwych fizycznych zdalnych hostów. Więc przypuszczam, że to sprawdzenie jest wykonywane tylko wtedy, gdy połączenie przychodzi z „zewnątrz”.