4 Replies Latest reply on Sep 24, 2010 3:16 PM by Udo

    OC4J Location for apex-config.xml

      We are running OC4J version on Windows 2003 server. I have deployed the most current apex.war file and have modified the web.xml file to adjust the location of the apex-config.xml file using the config.dir setting. No matter what I set this value to and no matter where I place the apex-config.xml file, it always defaults to the ${java.io.tmpdir} location. The apex-config.xml file gets removed from this temporary location and the listener will not function after I sign off of the server.

      I know there has been bugs related to this, but is this supposed to be fixed and if not, when will there be a fix for this?
        • 1. Re: OC4J Location for apex-config.xml
          Does anyone know if there is a fix for this problem?
          • 2. Re: OC4J Location for apex-config.xml

            I had some issues with the config file on my Tomcat as well. What I did was first removing (and later patching) the war file from my webapps directory, so restarts could never lead to reloading the original web.xml. The first start of the application seemed to take the tmpdir, so I stopped the Tomcat, cleaned up temp completely, restarted it and from that point, the listener always uses my config.dir.
            Perhaps this procedure may solve your problem too. Especially cleaning temp also helps, when you use config.dir and not config.dir/<Mount Point>, because config.dir is only taken if the Listener doesn't find the apex-config.xml in tmpdir. You may check, if your config.dir you assume to be the one is actually the one to be taken first.
            Another thought: Is the file and the config.dir you entered really accessible for the OC4J? If the ACL doesn't allow read/write access for the account running the OC4J, that can possibly make the Listener create his file in the temp again.

            • 3. Re: OC4J Location for apex-config.xml
              I have the same issue and consider it to be a major problem.

              If the server is restarted, the APEX listentener configuration is deleted with the files in the tmp directory.

              I also want to use the same web server to connect to two different instances of APEX, but I don't see how this can be done when the APEX listener insists on using only one config file. This seems to mean that a seperate server is needed for every configuration of the APEX listener.

              I see that a fix for this is mentioned in this forum, but others have mentioned that the fix did not work. I haven't seen any response to this. Perhaps I am mistaken...

              Is there a fix that works? If so, how do we implement it? If not, then when might we expect this problem to be fixed?


              - Scott
              • 4. Re: OC4J Location for apex-config.xml
                Hi Scott,

                the listener does not support multiple DADs directly. If you don't use the embedded web server, you can deploy the war-file multiple times using different contexts. /apex is the default one as described in the installation guide. You could use /apex_1 /apex_2 or /my_context ... and have different deplyoments on the same server. Each deployment can have its own configuration which will be searched as follows (according to the install guide):

                The APEX Listener searches for the configuration file at the following locations in this sequence. The Mount Point refers to the name of the deployment on the webserver.

                1) $HOME/<Mount Point>/apex-config.xml
                2) ${config.dir}/<Mount Point>/apex-config.xml ( from web.xml )
                3) ${java.io.tmpdir}/<Mount Point>/apex-config.xml (default for new installs )
                4) $HOME/apex-config.xml
                5) ${config.dir}/apex-config.xml ( from web.xml )
                6) ${java.io.tmpdir}/apex/apex-config.xml (default for new installs )

                I configure my deployments to take 5) on single installations or 2) for installations with multiple DADs. You could also use 1) to avoid reconfiguring the web.xml. I think many people run into trouble because the web.xml is overwritten by autodeployment again when the server or the application restarts from the original war-file. As mentioned above, I patch the warfile to contain my modified web.xml, so all my changes will persist.


                Edited by: Udo on 24.09.2010 17:15
                Note that you need to restart the application after modifying the web.xml after deployment. If you don't restart but reload, your change will be lost if you don't patch the corresponding war.