Совместное расположение EAR Java EE для ресурсов чтения / записи в кластерной среде - PullRequest
Новая
       32

Совместное расположение EAR Java EE для ресурсов чтения / записи в кластерной среде

4 голосов
/ 19 июля 2010

В среде Java EE (случается, что это WAS 6.1, но это может быть любой сервер приложений) мне нужно разместить XML-файл, который является файлом конфигурации, чтобы я мог читать и записывать в него.

Это должно быть доступно в кластерной среде, поэтому я смотрю на использование пути к классам для загрузки файла.

Я думаю, что могу сохранить этот файл в корне EAR, сослаться на него в манифесте, а затем загрузить и сохранить его.

Я попробовал этот подход, поместив мой файл в JAR и сделав его доступным через МАНИФЫ, и я могу без проблем загрузить файл конфигурации из пути к классам, используя следующее. 

this.getClass().getClassLoader().getResourceAsStream("configFileName");

Это загружает файл, который находится в JAR, который является фантастическим. Но если я хочу редактировать этот файл программным способом, я не могу получить доступ к расположению файлов JAR (корень EAR), он возвращает мне интерпретированный путь, подобный этому: 

 /usr/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/MyApp.ear/MyApp.war/TB_config.jar

Это не правильное местоположение JAR, правильное местоположение на MyApp.ear.

Итак, вопрос: как я могу получить доступ и обновить (скопировать содержимое, создать новый, сохранить, удалить старый) JAR с моим файлом конфигурации.
Или я должен положить файл конфигурации в другом месте?

Что такое стандарт Java EE, чтобы сделать файлы, которым требуется доступ на чтение / запись, доступными для WAR в кластере?

Ответы [ 4 ]

2 голосов
/ 16 декабря 2010

Хорошо, я построил решение для этого. Это больше основано на WebSphere (наша платформа), но это J2EE, и я удивлен, что это не упоминалось. В основном я использовал JMX для синхронизации узлов. Файлы сохраняются и сохраняются в диспетчере развертывания, после чего узлы повторно синхронизируются с использованием вызовов JMX, а затем механизмы, содержащие приложения, перезапускаются путем вызова сервлетов в приложениях.

Работает мечта

Итак, @stacker, узлами управляют, а менеджер распределяет файлы по узлам.

2 голосов
/ 19 июля 2010

Проблема, с которой вы столкнулись, не уникальна.Многие программисты Java EE могут бороться с предоставлением «настраиваемого» файла свойств администраторам кластера.И решение, которое вы выбрали, хорошо, имеет свои ограничения.

Проблема с вложением файла конфигурации в JAR, это абсолютный путь или физический путь файла, на случай, если вам нужно его обновить,Если ваш контейнер не взорвет ваши файлы EAR и WAR, то размещение файла конфигурации рядом с кодом - плохая идея - администратору придется развернуть более новую версию EAR / WAR / JAR.Это, если, конечно, вы не можете настроить контейнер для взрыва артефактов - это делает WebLogic Server, я не уверен насчет WAS.

Есть несколько способов решения этой проблемы:

  • Сохраните файл конфигурации в сети SAN, которая доступна для всех узлов в кластере по «каноническому» пути.Таким образом, вы можете найти файл в любом узле кластера и обновить его.Напомните себе, чтобы ограничить доступ к этому каталогу.Хотя это звучит просто, это не обязательно - объекты Java, возможно, придется «сбрасывать» между узлами после обновления файла конфигурации.Более того, вам может потребоваться сценарий, в котором файлы свойств могут редактироваться вне приложения.
  • Использовать базу данных.Гораздо проще и почти без проблем, за исключением того, что объекты Java, возможно, придется очищать снова.
  • Используйте MBean.Так же хорошо, как база данных, за исключением того, что я не знал, что многие люди заявляют о поддержке MBean в WAS.Кроме того, я не совсем уверен, могут ли состояния объекта проходить через кластер в этом случае.
1 голос
/ 19 июля 2010

Вы не можете записать в файл ear, вы должны поместить XML-файл в БД в виде текстового объекта (большой объект).

0 голосов
/ 20 июля 2010

На самом деле, поскольку я использую WebSphere, похоже, я могу использовать динамический кеш, предоставленный администратором развертывания WebSphere. В последней главе приведенной ниже ссылки описывается использование динамического кэша для предоставления общего объекта в кластере. Файл конфигурации представляет собой XML, который анализируется как таковой механизмом (в объект Document) приложения и, таким образом, является объектом Java, поэтому он может быть помещен в DistributedMap.

Похоже на чистое решение. Спасибо всем за чтение и ваши ответы.

http://www.ibm.com/developerworks/websphere/library/techarticles/0606_zhou/0606_zhou.html

...