Oracle forms not starting with JRE and IE8

Most likely a hot debated topic at the sites of many Oracle EBS customers is the question if they would like to stay on Oracle jInitiator or to make the switch to the JRE approach.

Oracle E-Business Suite makes use of Oracle forms which is a Java application for witch you have to load some .jar files onto your local browser who will take the client software role. Oracle always used jInitiator for this which used to do this task. Recently Oracle made a switch to a new approach and started to advocate the use of Sun Java Runtime Environment or JRE for short.

This also makes it possible to start your forms part of Oracle E-Business suite from Internet Explorer 8 for example and other browsers like FireFox. This was possible in the past however would take some hacking from the users who wanted this to happen. As most customers are upgrading their workstations and browsers to a newer versions it is feasible to go for the JRE option.

The following things need to happen:

(A) You have to apply patches on your server and make it ready for JRE.
In this case you should review metalink note 290807.1 which informs you about all the steps needed to take to make this happen on the server side.

(B) you have to make sure the correct version of JRE is installed on (or gets installed) on your clients.

Due to some bugs it is very important to look for which version is the best at the moment you start this project. My best advice would be to keep an eye on the weblog of Steven Chan for this subject and start a service request at metalink before you make a decision.

Even if you have taken all the steps to make sure all should work fine you can run into problems with some clients which for some reason will refuse to start a new forms session. I recently had this issue at a client and it later turned out to be a networking/firewall/proxy issue. The best way to start debugging in those cases is the logging in JRE which is not very known to many people.

Open the Java Control Panel and go to the advanced tab. Here can activate tracing and logging. When you have activated those try to start a forms session again and review the log and trace file.

The resulting files can be found at "\Sun\Java\Deployment\log" and do contain a lot of useful information for you debugging. I would like to advise to always do a trace/log first on the client in cases you have problems on a client starting the forms session with JRE instead of Oracle jInitiator.

Oracle VM presentation

Just in case you missed (somehow) the fact that Oracle is having a stack of virtualization software you might have a look at the link below to the flash demo of Oracle VM.

Oracle VM is a server virtualization solution, this is different from for example a virtualbox installation where you run the virtualization software on your host Operating System and inside this software you run a virtual machine.

The Oracle VM solution is build upon the technology from the opensource project Xen in which Oracle is also donating a code and resources.

Even though I already posted, and will post more, information on Oracle VM from a technical point of view I love to share the below link with you which you can share with people who are getting into virtualization for the first time.

Flash demo of Oracle VM.

Subversion TCP4 and TCP6

I recently received the request to setup a new source repository for an international team located in India and Europe who will share code during development cycles. The main development will be done on Oracle PL/SQL code and due to the fact that TOAD has support to connect to Subversion and Subversion is know to most developers the decision was made to setup a subversion machine.

Even though I installed and used subversion systems before I now encountered something new. After installing subversion and starting svnserve I was unable to connect. checking if the daemon was running and checking the config it turned out all to be correctly running. Finnaly it leaded us to the networking part of the server. And even then it took me a second look before spotting the issue.

running a netstat -l grep svn command gave me the following line:
tcp6 0 0 [::]:svn [::]:* LISTEN

The second time I looked at the result it turned out that the subversion server was listing under the IPv6 protocol instead of the exepected IPv4.

When yous start svnserve you start it normally with svnserve -d to get it running in a deamon mode. It turns out that, at least under debian, it will pick the IPv6 protocol instead of the IPv4. you can solve this starting the deamon with the following command instead:
svnserve -d --listen-host=0.0.0.0

If you check your netstat info after that you will see the following:
tcp 0 0 *:svn *:* LISTEN

Now it was running on IPv4 and all my network routing was working and I was not blocked somewhere along the route.

Ubuntu install Oracle MOD_OWA

Recently I tried to install MOD_OWA on a Ubuntu Linux machine running a Oracle 11G database. MOD_OWA if the opensource alternative for Oracle mod PL/SQL and is providing a bridge between your Apache webserver and your oracle database. In your database you can develop code to generate HTML documents which are send via your webserver to the client requesting it.

The original intention was to install mod PL/SQL however due to the fact this is more demanding on your machine resources and I only needed it on my laptop to do some coding during commuting between home, work and customers I decided to install MOD_OWA instead as it is covering most of the things I need and the code developed on MOD_OWA is portable for most parts to a MOD PL/SQL installation.

Oracle is running a great guide on the oss.oracle.com website on how to install and use MOD_OWA on a linux installation. After my first failed attempt to install it I followed the guide from Doug McMahon step by step. Even after this I still received a ORA-01804 error when I tried to request any page via MOD_OWA. After consulting with Doug we came to the conclusion that it most likely had something to do with the settings of a $ORACLE_HOME variable.

Checking the $ORACLE_HOME variable for the user running Oracle and the user running Apache resulted in a conclusion that it was set correctly for those users. However, as it turns out Apache is ahving some issues with system variables set for the user running Apache and passing those variables to the child processes. One can see the error clearly when you do a strace (strace - trace system calls and signals) on the Apache processes and request the page that is giving you the error.

//-----------------------------------------------------------------------------------------------------------------
7910 lstat64("/var/tmp/oradiag_jolouwer/diag/clients/user_jolouwer/host_428099999_76/alert/log.xml", {st_mode=S_IFREG0640, st_size=3744, ...}) = 0
7910 stat64("/var/tmp/oradiag_jolouwer/diag/clients/user_jolouwer/host_428099999_76/alert/log.xml", {st_mode=S_IFREG0640, st_size=3744, ...}) = 0
7910 gettimeofday({1273129673, 750457}, NULL) = 0
7910 lstat64("/var/tmp/oradiag_jolouwer/diag/clients/user_jolouwer/host_428099999_76/alert/log.xml", {st_mode=S_IFREG0640, st_size=3744, ...}) = 0
7910 open("/var/tmp/oradiag_jolouwer/diag/clients/user_jolouwer/host_428099999_76/alert/log.xml", O_WRONLYO_CREATO_APPENDO_LARGEFILE, 0660) = 11
7910 write(11, "
In this part of the tracefile you will see on the last line a write statement including a part of a string "Unable to find environment varia". Above 2 files are mentioned. When one checks the log.xml file you will see a entry similar as the one below:

Unable to find environment variable: ORACLE_HOME

This is already telling you that the issue might resides in the $ORACLE_HOME settings even if you already checked this is set correctly for the users running Oracle and Apache. The sqlnet.log file will have a entry as the one below:

Thu May 06 16:43:38 2010

Unable to find environment variable: ORACLE_HOME

It turns out that when you run this combination in Apache you have to make a entry in the file /etc/apache2/envvars . The file wil state in its comments "Since there is no sane way to get the parsed apache2 config in scripts, some settings are defined via environment variables and then used in apache2ctl, /etc/init.d/apache2, /etc/logrotate.d/apache2, etc." So we know some issues might be present when it comes to parsing env variables. So if you add your Oracle env settings in this file and stop/start Apache you will notice that the problem is resolved.

I added the following:
export ORACLE_HOME=/u01/app/jolouwer/product/11.2.0/dbhome_1

export ORACLE_BASE=/u01/app/jolouwer

export ORACLE_SID=orcl

export ORACLE_UNQNAME=orcl

According to Doug he did not find this issue on any other system than the Ubuntu setup I used with a Oracle 11G Release 2. However, if you ever encounter this error when you setup MOD_OWA on a Linux box you might want to check your /etc/apache2/envvars file and try to add your ORACLE_HOME, ORACLE_BASE, ORACLE_SID and ORACLE_UNQNAME to this file.