Unresolved reference to WseeFileStore

Question

I am trying run SOA Suite and when I execute startWeblogic.sh I got the following message error:

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

Does anyone know how to fix this error?

I am running the system over 64 bits Suse

Answer 1

The quick and dirty way to get your admin server back up:

• cd to <domain name>/config
• Back up config.xml just in case
• Edit config.xml, find and remove the <saf-agent> tags that point to your non-existent WseeFileStore

When you have the admin server back up. You can look at the Store-and-Forward Agents and Persistent Stores links to see what is already configured there. It sounds like a SAF agent was somehow created but the backing Persistent Store was not.

You can always created the Persistent Store later and add that SAF agent back in if you need it.

Answer 2

This happens simply because the automated tool used to adapt the config.xml file to the new cluster structure is... well, far from efficient. It can create all other relevant structures ok, but the <saf-agent> entry is wrongly created.

Just open and look briefly to the config.xml file and you should see that something is not right with this entry.

I will use my environment as an example for this situation:

I have a single cluster with two managed servers named osb1 and osb2. Both are administered by the cluster's AdminServer and all these components are in a single machine called rdaVM. The whole domain was created with the Configuration wizard and, upon the first AdminServer start, I've got that dreadful error for quite some time. The solution does reside in the config.xml file located in <DOMAIN_HOME>/config/config.xml When I opened this file in the editor and did a quick search for WseeFileStore I got some curious entries:

<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>

and

<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>

but looking at the offending entry:

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

Obviously there's something missing here. Looking at the <DOMAIN_HOME> I could see two folders there: WseeFileStore_auto_1 and WseeFileStore_auto_2. So no WseeFileStore and hence that annoying error. Also, the saf-agent element doesn't have a target. Solution: using just the underlining logic, I adapted the <saf-agent> entry to:

<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>

I.e, created a <saf-agent> for each of the cluster's managed servers, targeted each entry to a managed server and added the _auto_# suffix, where # is the ordering number for each managed server, to the <name> and <persistent-store> entries. After it, I was able to run the startWebLogic.sh script without problems (from this source at least...)