Неразрешенная ссылка на WseeFileStore

Question

Я пытаюсь запустить SOA Suite, и при запуске startWeblogic.sh я получил следующее сообщение об ошибке:

Unresolved reference to WseeFileStore by [<domain name>]/SAFAgents[ReliableWseeSAFAgent]/Store

at weblogic.descriptor.internal.ReferenceManager.resolveReferences(ReferenceManager.java:310)
at weblogic.descriptor.internal.DescriptorImpl.validate(DescriptorImpl.java:322)
at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:332)
at weblogic.management.provider.internal.DescriptorManagerHelper.loadDescriptor(DescriptorManagerHelper.java:68)
at weblogic.management.provider.internal.RuntimeAccessImpl$IOHelperImpl.parseXML(RuntimeAccessImpl.java:690)
at weblogic.management.provider.internal.RuntimeAccessImpl.parseNewStyleConfig(RuntimeAccessImpl.java:270)
at weblogic.management.provider.internal.RuntimeAccessImpl.<init>(RuntimeAccessImpl.java:115)
... 7 more

Кто-нибудь знает, как исправить эту ошибку?

Я использую систему с 64 битами Suse

Answer 1

Быстрый и грязный способ восстановить ваш сервер администратора:

• кд <domain name>/config
• Сделайте резервную копию config.xml на всякий случай
• Отредактируйте config.xml, найдите и удалите <saf-agent> теги, которые указывают на ваш несуществующий WseeFileStore

Когда у вас есть резервный сервер администратора. Вы можете посмотреть на Store-and-Forward Agents а также Persistent Stores ссылки, чтобы увидеть, что там уже настроено. Похоже, что агент SAF был каким-то образом создан, но резервное хранилище не было.

Вы всегда можете создать Persistent Store позже и добавить этого агента SAF обратно, если вам это нужно.

Answer 2

Это происходит просто потому, что автоматизированный инструмент, используемый для адаптации файла config.xml к новой структуре кластера,... далеко не эффективен. Это может создать все другие соответствующие структуры, но <saf-agent> запись создана неправильно.

Просто откройте и кратко посмотрите на файл config.xml, и вы увидите, что с этой записью что-то не так.

Я буду использовать свою среду в качестве примера для этой ситуации:

У меня есть один кластер с двумя управляемыми серверами с именами osb1 и osb2. Оба администрируются кластерным AdminServer, и все эти компоненты находятся на одном компьютере под названием rdaVM. Весь домен был создан с помощью мастера настройки, и при первом запуске AdminServer я довольно долго получал эту ужасную ошибку. Решение находится в файле config.xml, расположенном в <DOMAIN_HOME>/config/config.xmlКогда я открыл этот файл в редакторе и выполнил быстрый поиск WseeFileStore, я получил несколько любопытных записей:

<jms-server>
  <name>WseeJmsServer_auto_1</name>
  <target>osb1</target>
  <persistent-store>WseeFileStore_auto_1</persistent-store>
</jms-server>
<jms-server>
  <name>WseeJmsServer_auto_2</name>
  <target>osb2</target>
  <persistent-store>WseeFileStore_auto_2</persistent-store>
</jms-server>

а также

<file-store>
  <name>WseeFileStore_auto_1</name>
  <directory>WseeFileStore_auto_1</directory>
  <target>osb1</target>
</file-store>
<file-store>
  <name>WseeFileStore_auto_2</name>
  <directory>WseeFileStore_auto_2</directory>
  <target>osb2</target>
</file-store>

но, глядя на оскорбительную запись:

<saf-agent>
  <name>ReliableWseeSAFAgent</name>
  <store>WseeFileStore</store>
</saf-agent>

Очевидно, здесь чего-то не хватает. Глядя на <DOMAIN_HOME> Я мог видеть две папки там: WseeFileStore_auto_1 и WseeFileStore_auto_2. Так что нет WseeFileStore и, следовательно, эта досадная ошибка. Кроме того, элемент saf-agent не имеет цели. Решение: используя только подчеркивающую логику, я адаптировал <saf-agent> вход в:

<saf-agent>
  <name>ReliableWseeSAFAgent_auto_1</name>
  <target>osb1</target>
  <store>WseeFileStore_auto_1</store>
</saf-agent>
<saf-agent>
  <name>ReliableWseeSAFAgent_auto_2</name>
  <target>osb2</target>
  <store>WseeFileStore_auto_2</store>
</saf-agent>

То есть создал <saf-agent> для каждого из управляемых серверов кластера нацелен на каждую запись на управляемый сервер и добавлен _auto_# суффикс, где # номер заказа для каждого управляемого сервера, к <name> а также <persistent-store> записей. После этого я смог без проблем запустить скрипт startWebLogic.sh (по крайней мере, из этого источника...)