From the /opt/coldfusion9/logs/cfserver.log
The init.d startup script may refer to an explicit Java path and Java binary (but this is not the only location it may be set):
/etc/init.d/coldfusion -> /opt/coldfusion9/bin/coldfusion
The init.d script cfstart routine may prepare another file "jvm.config" for sourcing override settings
For example the jvm.config file may exist in:
And to get it ready a symlink is created in the
[NOTE: This is so that when the ELF binary "senses" or detects an optional jvm.config in its default execution directory it will automatically source its contents.]
Where $CFSTART is:
CFSTART='$SUCMDFILE -s /bin/sh $RUNTIME_USER -c "export PATH=$PATH:$CF_DIR/runtime/bin; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH; cd $CF_DIR/runtime/bin; nohup $CF_DIR/runtime/bin/coldfusion9 -jar jrun.jar -autorestart -start coldfusion &"'And /opt/coldfusion9/runtime/bin/coldfusion9 referred "to" in the CFSTART command string is an ELF binary that sources a jvm.config file
The jvm.config may contain an optional override at the top with appropriate "warnings":
Since the path /usr/lib/jvm/java-1.6.0-openjdk-126.96.36.199.x86_64/jre/ is "explicit" and does not point at the convention in RHEL /usr/lib/jvm/jre which is normally
/usr/lib/jvm/jre -> /etc/alternatives/jreand is updated by the alternatives method when updating the actual java runtime installed for the operating system.
/etc/alternatives/jre -> /usr/lib/jvm/jre-1.6.0-openjdk.x86_64
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64 -> java-1.6.0-openjdk-188.8.131.52.x86_64/jre
Explicitly pathing is "brittle" and will break without warning when a regular # yum update command is run to update all the packages in a RHEL or like operating system.
Therefore, if you are being explicit in order to "control" the version of Java being used by an application, also be aware you may want to "pin" or "versionlock" a specific package so it isn't unintentionally updated without warning
$ sudo yum install yum-plugin-versionlock
Also be [aware] that RHEL5 and RHEL6 have different versionlock plugin pacakge names.
For RHEL5 it is:
# yum install yum-versionlock# rpm -qa|grep java >> /etc/yum/pluginconf.d/versionlock.list
For RHEL6 it is:
# yum install yum-plugin-versionlock# rpm -qa|grep java >> /etc/yum/pluginconf.d/versionlock.list
[consider if you versionlock a package; there are security implications if you do not regularly update the package, this is a perfectly rational procedure however if you need more time to test]
Or be sure to keep the /opt/coldfusion9/runtime/bin/jvm.config file up to date when updating the operating system java version.
Or do not define it here (jvm.config) and allow the settings in the /etc/init.d/coldfusion9 startup script to take priority.
Unfortunately Adobe documentation demonstrating explictly choosing a Java version to host the Coldfusion process "other than" the Java jre that comes with the product is brief and general, to the point of not describing pitfalls relating to regular patching and updating for bug fixes and security matters.