Installing Java 7 on OSX does not force Tomcat to use newly installed active JDK, instead it is still using the old .../CurrentJDK/Home mechanism. Java 7 Installation on OSX does not reside on conventional location on file system , which is being used by tomcat setclasspath.sh script. Excerpt from setclasspath.sh if [ -d "/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home" ]; then export JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home" Solution to the problem is to update setclasspath.sh script to ; if [ -d "$(/usr/libexec/java_home)" ]; then export JAVA_HOME=$(/usr/libexec/java_home)
> > Solution to the problem is to update setclasspath.sh script to ; > The correct solution is to write your own setenv.sh script that sets JAVA_HOME or JRE_HOME variable as appropriate for your system, as documented in RUNNING.txt. I do not mind improving the auto-detection logic, but 1. Do you have some official docs, regarding what JDK/JRE versions install where? Why one path and not the other? If there are several paths, what is the precedence in looking through them? 2. Patches are to be provided in "Unified diff" format, http://tomcat.apache.org/bugreport.html#How_to_submit_patches_and_enhancement_requests
IIRC, the correct and "official" (whatever that means) way of determining the JDK that has been set up as the default on Mac OS X is to run the command /usr/libexec/java_home. For example, on a system running Apple Java 6 and Java 7 OpenJDK and with Java 7 set as the default, I get this: $ /usr/libexec/java_home /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home $ `/usr/libexec/java_home`/bin/java -version java version "1.7.0_07" Java(TM) SE Runtime Environment (build 1.7.0_07-b10) Java HotSpot(TM) 64-bit Server VM (build 23.3-b01, mixed mode) On a system with only Apple Java 6 instealled, I get this: $ /usr/libexec/java_home /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home $ `/usr/libexec/java_home`/bin/java -version java version "1.6.0_33" Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-10M3720) Java HotSpot(TM) 64-bit Server VM (build 20.8-b03-424, mixed mode) It took me a long time (hours) once upon a time to figure out how to correctly determine the default Java on Mac OS X, and this appears to be it. It would seem to me that, on Mac OS X, Tomcat should utilize the /usr/libexec/java_home command to determine JAVA_HOME when JAVA_HOME is not previously set. Just my $0.02.
(In reply to comment #2) > IIRC, the correct and "official" (whatever that means) way of determining > the JDK that has been set up as the default on Mac OS X is to run the > command /usr/libexec/java_home +1 I'm not sure how far back in history this command goes, though. For instance, does 10.0.0 include it? The man page does not include any version information for the utility itself (at least on 10.8.2). It's definitely worth checking for /usr/libexec/java_home and using it if it's there, though. For those who don't know, 'java_home' allows multiple JVM versions to be installed side-by-side and the user may choose which one she wants for which purposes. I don't see a reason not to use the standard "use the user's current top-preference JVM" which is the default operation of 'java_home'.
Apple documentation suggests using /java_home utility to determine the JAVA_HOME http://developer.apple.com/library/mac/#qa/qa1170/_index.html it suggests as "Another advantage of dynamically finding this path, as opposed to hardcoding the fixed endpoint, is that it is updated when a new version of Java..." Oracle also relying/using on the existing mechanism as they suggest using it at http://docs.oracle.com/javase/7/docs/webnotes/install/mac/mac-install-faq.html even though they suggested how to continue to use older apple versions of JDK executing /usr/libexec/java_home -X suggest that it maintains the plist for all installed jdk frameworks in osx terms. Other benifit of using java_home utlility, is its always available as i like to run tomcat via launchd, and i m sure all osx server installations will do
Worth mentioning: this is an improvement to bug #37284.
Fixed in trunk and 7.0.x. Will be in Tomcat 7.0.35. Proposed for 6.0.x.
just for knowledge, as i am bit knew to apache bugzilla. last comment does that mean proposed changes has been accepted
(In reply to comment #7) > just for knowledge, as i am bit knew to apache bugzilla. last comment does > that mean proposed changes has been accepted It has been accepted for 7.0.x and 8.0, but still needs to be voted on for 6.0.x.
Thnaks
Fixed in Tomcat 6.0.x. Will be in 6.0.37.