protected
означает, что вы можете вызывать этот метод только из того же класса и из подклассов. То, что вы хотите сделать, невозможно. Ключевое слово protected
было бы бессмысленным, если бы вы могли называть эти методы повсюду.
В C ++ ключевое слово friend
для достижения желаемого: есть имя Child как friend
Observer ( это должно быть сделано изнутри Observer), а затем вы можете вызывать все методы в Observer (включая частные и защищенные) из методов Child. Но для PHP такого ключевого слова не существует.
документация предполагает, что агент JMX использует локальный порт - что-то недостижимое снаружи машины - если Вы не указываете следующее свойство:
com.sun.management.jmxremote.port=portNum
Это из соображений безопасности, а также по причине, приведенной Мистером Картофельная Голова. Таким образом похоже, что Java 6 не открывает значение по умолчанию удаленно доступный порт для JMX.
РЕДАКТИРОВАНИЕ: Добавленный после того, как OP добавил ответ с большей информацией.
Другая опция, которую Вы имеете, состоит в том, чтобы так или иначе создать локальный прокси, который слушает все локальные соединения JMX и экспортирует эту информацию. Таким образом, у Вас не должно быть такой волшебной конфигурации каждого экземпляра JVM на сервере. Вместо этого локальный прокси может соединиться со всем JVMs через JMX и затем так или иначе выставить эту информацию удаленно. Я не положителен точно, как Вы реализовали бы это, но что-то вроде этого может быть меньшим количеством работы, чем, что иначе необходимо сделать для представления всех JVMs удаленно через JMX.
документация , кажется, указывает, что агент JMX использует локальный эфемерный порт, , если Вы не указываете следующее свойство:
com.sun.management.jmxremote.port=portNum
портов Default избегают, потому что Вы могли иметь многие JAVA-приложения в одной системе, и если бы был порт по умолчанию, то только одно приложение смогло бы управляться! Вышеупомянутое свойство конфигурации обеспечивается для специальная цель из удаленное управление.
, Если необходимо настоять на том, чтобы использовать эфемерный порт, затем URL агента JMX должен быть доступным из JVM через следующее системное свойство (хотя это, вероятно, будет локальным адресом):
com.sun.management.jmxremote.localConnectorAddress
Примечание : Я предполагаю, что Вы могли всегда открывать сокет на удаленно доступном адресе и проксировать запросы на локальном сокете, но использование доступного варианта кажется намного более привлекательным!
Так, короткий ответ на мой вопрос является "нет".
Однако интересно исследовать почему. Посмотрите эти netstat
вывод от допустимого локального соединения. Вот порты, которые я вижу открытый в результате jconsole
устанавливание локальной связи с собой. Как Вы видите, порт 1650 является локальным портом, используемым для получения информации JMX:
Proto Local Address Foreign Address State
TCP Gandalf:1650 Gandalf:1652 ESTABLISHED
TCP Gandalf:1650 Gandalf:1653 ESTABLISHED
TCP Gandalf:1650 Gandalf:1654 ESTABLISHED
TCP Gandalf:1650 Gandalf:1655 ESTABLISHED
TCP Gandalf:1650 Gandalf:1656 ESTABLISHED
TCP Gandalf:1652 Gandalf:1650 ESTABLISHED
TCP Gandalf:1653 Gandalf:1650 ESTABLISHED
TCP Gandalf:1654 Gandalf:1650 ESTABLISHED
TCP Gandalf:1655 Gandalf:1650 ESTABLISHED
TCP Gandalf:1656 Gandalf:1650 ESTABLISHED
Однако не достаточно попытаться соединиться jconsole
с localhost:1650
. К сожалению, весь, который будет, сеть Вы является "Отказавшим соединением: никакой такой объект в таблице" сообщение.
Так, заключение моей исходной истории состоит в том, что, если мы собираемся упростить дистанционный мониторинг с помощью JMX для наших клиентов, мы действительно должны определить уникальные отдельные порты удаленного доступа для множества процессов Java, которые запускаются в нашей системе. К счастью, все это требует, разумное использование аргумента VM:
com.sun.management.jmxremote.port=portNum
, где у нас почти наверняка будет последовательный предуказанный диапазон portNum
так, чтобы клиент мог выбрать корректное удаленное приложение с помощью номера порта.