Dual Booting the ALUI Portal

What's a common quality of most developers and system administrators? Laziness. I am, unfortunately, no exception to this rule. It is because of this laziness I decided to see if it would be possible to dual boot an ALUI portal instance on my laptop. Let me step back...

What do you mean Dual Booting?

What I mean by dual booting the portal is being able to run (perhaps simultaneously) 4 different common configurations of the portal foundation:

• a .NET/IIS instance
• a Java/Weblogic/Tomcat instance
• an Oracle XE/10g instance
• a SQL Server instance

Ideally, this is done with minimal configuration and/or hassle. Of course getting all of the environments working means modifying some of the config files, so running all of the environments at the same time would take some screwing around with environment variables and install directories that I am just too lazy to do.

This can be useful for a number of different reasons. In my case it can become a necessity if I'm transitioning from a client that wants me to develop using the server API in .NET to a client running on Solaris who wants a Java-based automation server script. Maybe this isn't a 'normal' scenario for you, but maybe you want to evaluate different capabilities of the product or just play around. Either way, I thought my laziness might make an interesting article.

How do I do It?

Luckily, it doesn't take much. Since many of the portal's back-end services were designed with modularity in mind, as long as you know how to play with the right config settings you are probably almost there. This is not to say that this is either a supported configuration, or something you should consider doing in a production environment. Here's what I did:

1. Create an oracle SID and .NET database to house portal components. I used Oracle XE, so there was only one SID for me to use. Make sure both the user name and password for the plumdbuser are identical for both instances.
2. Install image server components to a static web server (apache, IIS). Optionally, create a DNS alias for the image server to allow easy switching (I also use an alias so I can host from different locations on a whim).
3. Install the .NET version of the portal (all components).
4. Install the Java version of the portal to the same directory  -- just the administrative server (use either database configuration).
5. Optionally install a Tomcat/Weblogic portal veresion as well (you can also just deploy the portal.war in multiple places, if this suits you).
6. Script the Oracle and SQL Server databases with the appropriate scripts in $PORTAL_HOME/sql.
7. Copy the jar files from the portal.war (use a zip file editor -- I prefer Winrar) to $PORTAL_HOME\webapp\portal\web\bin.
8. Modify $PT_HOME/settings/portal/portalconfig.xml in the following way:

• Set the WebHome value to $PORTAL_HOME/webapp/portal/web/bin
• Ensure database-connection:adonet-license-file-directory is set to $PORTAL_HOME/bin/assemblies in serverconfig.xml (this may be wrong if you installed .NET first).

At this point you have a base configuration which can be modified to support any web application server or database configuration.

To switch between weblogic/apache/tomcat/IIS:

• Modify AdminSiteBaseURL in $PT_HOME/settings/portal/portalconfig.xml to point to the appropriate port, restart appropriate web server

To support Oracle/SQLServer:

• Modify $PT_HOME/settings/common/serverconfig.xml by changing the following in the database component:
  - database-connection-port value should be set to 1433, 1521 or other port
  - database-connection:dbtype value should be set to either oracle or mssql
  - if not using Oracle, comment out database-connection:dbname

If any custom components have been installed in one environment, it may be necessary to edit the Custom*.xml files to add/remove libraries.

Of course, there are some things which may seem a bit 'off'. If you look in the server settings in your Administrative Utility dropdown, you may see some wacky URL's. On the whole, though, you should be able to build, test and compile Server API code for any platform, and probably run most of the embedded application servers as well.

A follow up question many of you may have is why I don't just run a VM image of the environment I want (many of my colleagues do this). The answer is twofold: 1.) a VM provides an annoying performance lag, and 2.) that would mean I would have to actually move my source code/binaries around (remember the first sentence of this article?).