| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > JVM монитор |
| Автор: access 1.10.2010, 14:11 |
| Доброго дня! Придумал себе проблему - необходимо мониторить одно MDI свинг-приложение. В общем, пытаюсь намалевать некий обработчик событий, а скорее даже - напоминалку. Мне нужно: (в предположении, что есть некая либа, которая отслеживает состояние виртуальной машины) 1) По запросу из приложения делается snapshot памяти jvm - получаю список всех событий, значений всех переменных, компонент на форме и их проперти, etc... (наподобии информации из окна Frame в IDEA во время дебаг-режима) 2) Далее, на основе snapshot-а уже сам пользователь (сам пользователь - это я) анализирует, например, что в данный момент запущен MyFrame1.class, у которого в момент нажатия кнопки bCalc переменная (вернее - некоторое проперти text) tfAccount.text = '417' (в окне Frame путь такой: tfAccount->ui->editor->model->s, глубоко запрятано). На основе этого анализа создаю и сохраняю такой шаблон (условно): Param1='Frame', Param2='JButton.ActionPerformed'; Param3='tfAccount.text'... Имея такой шаблон, пусть называется "Расчет определенного Лицевого Счета", создаю для него события: Param1='MyFrame1', Param2='bCalc'; Param3='417'... Message = "Внимание! Сделайте перерасчет" Param1='MyFrame1', Param2='bCalc'; Param3='510'... Message = "Проведите доначисление 150.34" сохраняю их пусть в базу. 3) Приложение работает, имея в памяти карту событий, где-то в фоне крутится тот самый монитор JVM, который раз, например, в 2-3 секунды делает snapshot-ы и сравнивает их по определенным параметрам из карты событий, если попадает на такое событие ( в данном модуле была нажата кнопка bCalc и при этом текстовое значение tfAccount было равно 510), то вылетает сообщение: "Проведите доначисление 150.34" Для чего всё это нужно. Пользователь, который будет делать шаблоны, это я сам, шаблоны будут создаваться не так уж и часто, но будут. Сделано всё так хитро, потому что не хочу переписывать код приложения, вставляя обработку по типу if (e.getSource()==bCalc && tfAccount.getText()==param1) { // show event-message } Шаблоны, может заморочно, но создать смогу, пользователи уже сами будут создавать события, заполняя те или иные параметры. Т.е. основная мысль - не переписывая код приложения сделать возможность реагировать на те или иные события. Своего рода - напоминалка. Наверное, это должно быть что-то вроде jps, jstat, jmap, но как-то там инфы мало (или я поверхностно - не углядел), да и хотелось бы всё-таки либу, отдельное приложение не годится. Есть ли такое в природе? Ну, и главный вопрос: может быть всё это делается как-то иначе - направьте, чтоб я велосипед с двумя рулями не изобретал. |
| Автор: jk1 1.10.2010, 14:52 |
| Как-то очень сложно выглядит решение. Почему бы просто не сделать конфигурационный файл с описанием условий проверок и текстом сообщений, а внутри приложения сделать движок-валидатор, работающий на основе конфигурационного файла? Если используется СУБД, то еще проще: кладем все это в таблицы и даже файла не надо. |
| Автор: access 1.10.2010, 15:03 |
| я вижу, что сложно, но по-простому на ум не приходит. Теперь по Вашему предложению: если будет придумано какое-то новое событие (в моей концепции - новый шаблон) - нужно будет переписывать под это события движок-валидатор, правильно понял? |
| Автор: jk1 1.10.2010, 15:24 | ||
Зависит от гибкости вашего валидатора. Например можно организовать регистрацию компонентов которые Вы можете захотеть мониторить в валидаторе, чтобы он мог (reflection) согласно конфигурации проверить их внутренности на валидность. Тогда ничего переписывать не надо будет. Кстати можно сделать цепочку валидаторов, подтягиваемых при помощи http://www.developer.com/java/article.php/10922_3848881_2/Service-Provider-Interface-Creating-Extensible-Java-Applications.htm. Как это будет выглядеть для вас? Появилось новое правило валидации - Вы пишете новую реализацию интерфейса и подкладываете в JAR без перекомпиляции и переписывания остального кода. Еще одно возможное решение - JMX. В его рамках Ваши объекты делают свои поля доступными для удаленного мониторинга. Мониторить любую переменную в пределах JVM может разве что полноценный профайлер, а это, помимо прочих неудобств и высокой сложности реализации может еще и нехилое снижение производительности дать. Да и не верится мне, что Ваши инварианты затрагивают вообще все переменные в приложении. |
| Автор: access 7.10.2010, 10:53 |
| спасибо за ответ! Вы правы, конечно, события не будут затрагивать ВСЕ переменные приложения, просто я решил подстраховаться на все случаи, в общем - очередное универсальное решение. В общем-то, задача была интересна мне самому, пользователю то всё равно, как всё это будет сделано и с каким уровнем универсальности. Вероятно, моя хотелка пока реализована быть не может, в том виде, в котором я это себе представляю. |