A month or two ago, I installed Oracle XML Publisher on my notebook. In order to run XMLP you need to run the “Oracle XML Publisher Enterprise start” (OC4J) via the Start Menu first. Next, you can run XMLP in your internet browser.

First it worked fine, but one day, XML Publisher wouldn’t start up anymore… and apparently the cause was the OC4J that failed to get up and running, as starting the OC4J start-up script resulted in the following error:

2006-12-04 09:47:57.453 ERROR Failed to set the internal configuration of the OC 4J JMS Server with: XMLJMSServerConfig[file:/C:/oracle/product/10.1.0/db_1/oc4j/ j2ee/home/config/jms.xml]As my knowledge of Java is very limited, and there was nothing else I could think of that would solve my problem, I decided to simply re-install XMLP and … it worked again. But after a while, the old problem came back … Only did re-installing the software not work this time …

I went to look in the OC4J log files, and found that apparently my IP-address had shifted. Via the command ipconfig, I figured out that the IP-address causing the OC4J not to start, corresponded to my Wireless Network Connection… I disabled the WNC, and … EUREKA! It worked fine again. At least: I was able to start XMLP again, and fortunately I had my LAN-cable plugged in, so that I could access the database and continue with what I was doing.

But still, I kept wondering what went wrong, and why it went wrong and what if I really need that wireless connection to be enabled, while using XMLP?

Recently, I found an answer:

“You have encountered a “safety feature”within the lightweight (pure java) OC4J Java Messaging System (JMS)implementation. The OC4J Java Messaging System creates a lock file to constrainaccess to a specific persistent message store to the single OC4J instance thatcreated it.”

“The persistence lock file capturesinformation about the OC4J instance that owns or previously owned thepersistence store and this information includes the IP address of the owningoc4j instance. During startup if the OC4J Java Messaging System (JMS) discoversthat a persistence store it has been configured to use has a lock file that itdoesn’t own it will abort the startup procedure to avoid data corruption.“

… where the IP-address at the beginning of the line is – coincidence or not … – my Wireless Network Connection!!! So, a change had taken place at the network level since I last started an OC4J instance, causing the OC4J not to start anymore.

The start-up problem can be resolved via the following steps:

Ensure that there is no running OC4J instance that is accessing the persistence store

Navigate to the “persistence” directory for the OC4J instance that fails to start

Remove the “.lock” files

When starting the XMLP OC4J instance, the *.lock files will be created again, but your OC4J will start without any problem, as they will contain the correct IP-address.