Best Practice on Pointing to Latest JDK in FMW Installation

 

One of the best practices in Oracle Middleware installations is to point to logical “latest” JDK directory in the configuration files. When you install e.g. WebLogic server 11g on Linux you need to have the JDK installed before starting up the WebLogic installation.

You might have installed e.g. JDK 1.7. rpm which installs the JDK into /usr/java and by default has the best practice directories “default” that points to “latest” and “latest” symbolic link that points to the latest/wanted JDK installation.

/usr/java might look like this:

drwxr-xr-x. 8 root root 4096 Feb 28 08:09 jdk1.7.0_75
lrwxrwxrwx. 1 root root   21 Feb 28 08:09 latest -> /usr/java/jdk1.7.0_75
lrwxrwxrwx. 1 root root   16 Feb 28 08:09 default -> /usr/java/latest

If you didn’t have the “latest” symbolic link there, you might be running older versions like JRockit or JDK6.

Despite of having the /usr/java/latest symbolic link, you will get the full real path suggested in the installer:

Despite of pressing “Browse…” and choosing the /usr/java/latest, the JDK path will not change in the installer. You will get “Please select appropriate JDK” error.

There are two options to go:

1. Install the software pointing to the real path and then later change all shell scripts etc. pointing to the real path, to point to /usr/java/latest

or

2. Exit the installer and change the real JDK directory name temporarily to /usr/java/latest, restart the installer and the installer will find the JDK in the path /usr/java/latest, configure the environment variables. After the installer has finished, change the real JDK path back to what it was and point the /usr/java/latest to point to the wanted JKD version.

Here are the steps for the option 2)

cd /usr/java

mv latest latest.old

mv jdk1.7.0_75 latest

Install the Oracle FMW software. When installing e.g. Weblogic server you should point the JDK to /usr/java/latest.

After the installation has finished, reverse the changes:

mv latest jdk1.7.0_75

mv latest.old latest.

 

You can veriry that the shell scripts point to this logical directory by looking at:

$MW_HOME/wlserver_10.3/common/bin/commEnv.sh.

SOA Suite 10g–> 11g migration and Issue with composite.xml Attributes

Here is a heads up for those that might still be working on 10g –> 11g migrations. There is one unfortunate bug (8980875) in the migration process that seems innocent in the beginning but has critical effects in the end.

I logged a service request for continuous XML parse errors in the managed server log files:

org.xml.sax.SAXParseException: <Line 5, Column 92>: XML-20129: (Error) Namespace prefix 'ui' used but not declared.

This occurs at deployment time. In most cases the deployed composite worked just fine.

Error comes from the composite.xml content where the migrated 10g SOA projects have all the XML root element “composite” attributes in a single line. The deployment parser seems to be some sort of home grown XML parser that assumes that all the attributes are physically separated in their own lines, like this:

<composite name="Archive"
           revision="1.0"
           label="2012-08-16_09-51-28_557"
           mode="active"
           state="on"
           xmlns="http://xmlns.oracle.com/sca/1.0"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
           xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
           xmlns:ui="http://xmlns.oracle.com/soa/designer/">
</composite>

and when the migrated projects have something like this:

<composite name="HelloWorld" revision="1.0" mode="active" state="on" xmlns:ui="http://xmlns.oracle.com/soa/designer/

in a single line, the deployment will give errors in this part. You might have some references in composite.xml pointing to external servers using “ui.wsdlLocation” like this:

<reference ui:wsdlLocation=http://mydevhost1.mydomain.com:8001/soa-infra/services/CommonExceptionHandling/CommonExceptionHandling.wsdl name="CommonException...

By default these should not affect the runtime environment since this is used at development time. Unfortunately combined with this bug 8980875, the pointer seems to stay in the runtime environment causing gray hairs when e.g. all of the sudden production environment has pointers to development environment. Changing this ui.wsdlLocation seems very hard if not possible using the built-in deployment scripts and default search/replace element descriptors.

In the end, the advice from me is to change all the migrated 10g –> 11g SOA projects manually to correct the composite.xml “composite” element attributes to their own lines. This will help greatly in the dev->tst->prd deployments avoiding those unwanted cross environment pointers.

SOA Suite 11g installation – How to start BAM and SOA servers the first time

 

After installing SOA Suite 11g there has been a few questions asked why SOA or BAM servers are not started up. After you start the Admin server from $ORACLE_HOME/user_projects/domains/soadomain –using startWebLogic.cmd, you will get the Admin server up with the built-in Enterprise Manager. When you login to the enterprise manager using http://hostname:port/em, you will see the status of other servers, like this:

Indication is that BAM server or SOA server are not started. You can try starting these servers from GUI (click on server and mouse right-click) if you have your node manager up and running. If you don’t, here are my steps to do this form command line (replace the “C:\product\FMW11G” with your installation directory and “soadomain” with your domain name) :

C:\product\FMW11G\user_projects\domains\soadomain\bin>startManagedWebLogic.cmd soa_server1

Enter username to boot WebLogic server: weblogic

Enter password to boot WebLogic server:

 

After this, the SOA server starts up and SOA server runtime files gets created under C:\product\FMW11G\user_projects\domains\soadomain\servers –directory.

To automate the startup, not having to enter username and password, you need to create file called boot.properties and place this under security directory. In my example the directory would be C:\product\FMW11G\user_projects\domains\soadomain\servers\soa_server1\security. You need to create this directory manually if you don’t have it.

Editing the boot.properties is familiar if you have dealt with WebLogic server:

username=weblogic
password=mypassword

Next time server is started up, it reads the credentials from boot.properties, encrypts them in this file and continues with startup process.

Above instructions apply to BAM server as well.

This should be the end result:

“Start all” script for Windows

Here is a sample Windows script to start all servers that belong to SOA Suite (defaults to being on SOA domain directory):

start "SOA Admin Server" startWebLogic.cmd
start "SOA Server" bin\startManagedWeblogic.cmd soa_server1
start "BAM Server" bin\startManagedWeblogic.cmd bam_server1

New SOA Suite Clustering Utility

For those the need to setup SOA Suite cluster, there is recently published SOA Clustering Utility in OTN:

http://www.oracle.com/technology/tech/soa/ha/soa_cluster_utility.zip

Documentation:

http://www.oracle.com/technology/tech/soa/pdf/oracle-soa-suite-clustering-utility-guide.pdf