5 Replies Latest reply on Mar 12, 2011 5:20 PM by Udo

    Deploying multiple apex.war for multi-application mod_plsql migration

      Hi everyone.

      I've just spotted that the latest release includes Flexible Parameter Passing so thought I'd try migrating a few applications.

      I understand that to replicate multiple DADs, the approach is to deploy the apex.war file multiple times in Glassfish to create multiple listeners - each with a different context path. Is that correct?

      I'm finding that the first deployment works fine - I go to:


      and I can configure the database connection and start page (soipmi_live.hello_world).

      However, when trying to configure the second deployment:


      I get a page that looks like no CSS files or other resources have been loaded - all the admin tabs are displayed on the same page. After trying to complete the form anyway and clicking "Save" - the form values don't appear to be retained when going back to the same page.

      What else should I be doing to deploy multiple listeners?

      Thanks for any help.
        • 1. Re: Deploying multiple apex.war for multi-application mod_plsql migration
          Before deploying apex.war for a second database, you have to unzip it, change the WEB-INF/web.xml file to point at a different place for the listener configuration file, then re-zip into a .war - nice time to change the name to match your new context path. Information about what to change is in comments in web.xml, and (I believe) in the installation docs.

          As for CSS files and other resources, this may depend on how you've configured the virtual /i/ directory that contains them. If both databases are running the same version of APEX, you can probably use the same one. However, if they are running different versions of APEX, each will need a different resource directory, and one or both copies of APEX will need to be configured to point at the resource directory that is appropriate. Remember that this must match your APEX version - latest version of the listener comes with the resources for the latest version of APEX, but if you are using an earlier version, you'll have replace it with the /images/ directory from your APEX installation.
          • 2. Re: Deploying multiple apex.war for multi-application mod_plsql migration
            (I'm not running Apex - just the PL/SQL Web Toolkit. I'm trying the Listener as a replacement for mod_plsql and OHS)

            I've looked at apex.war and I don't see any hard-coded paths. There are 2 commented out entries for "config.dir" "cache.dir" pointing to "${java.io.tmpdir}/APEX" and "${java.io.tmpdir}/APEX/cache" respectively.
            • 3. Re: Deploying multiple apex.war for multi-application mod_plsql migration
              It depends on your J2EE containers configuration whether java.io.tmpdir (which is also the default location) is defined globally (i.e. it has the same value for all deployments) or if it is context-dependend, so each application deployment will have a separate directory for that.
              But removing the comment-tags will allow you to define a directory different from the default and different from temp, which is a good idea after all for a file that shall persist restarts or temp-cleanups.

              1 person found this helpful
              • 4. Re: Deploying multiple apex.war for multi-application mod_plsql migration
                It seems an odd place to put the listener configuration file - a fixed sub-directory off a default temp directory. I wonder why the Listener designers didn't put the default location as a sub-directory of the context root, for example.
                • 5. Re: Deploying multiple apex.war for multi-application mod_plsql migration
                  At first, I had that thought too. Thinking about alternatives I found none that fits better. You have to have some location that exists and is writeable on all platforms. I'm not sure if there exists an environment variable like java.io.tmpdir that exists in all cases. And as deployment strategies definetly differ on the supported platforms, relative paths could be misleading, too. Another point could be the fact that the file will just disappear on redeployment again if you store it inside the application context. Of course, this might happen with the tmpdir as well, but after all, this is just a default that makes it easy to get the Listener up and running "out of the box". The recommendation is to reconfigure the location after the initial configuration is done.