A distribution as-is will not run with a JRE. This is because wrapper scripts look for executables associated with a JDK such as jdb etc, as well as java. These occur in the files $CATALINA_HOME/bin/setclasspath.bat and $CATALINA_HOME/bin/setclasspath.sh. The following patches alter these scripts in the following way: 1) they only look for the required files associated with a JRE, e.g. java. 2) if not found, the message has been changed to say that JAVA_HOME should point to a JDK or a JRE. Here is a patch for $CATALINA_HOME/bin/setclasspath.bat: --- setclasspath.bat Fri Oct 29 20:13:00 2004 +++ setclasspath2.bat Fri Nov 5 10:57:56 2004 @@ -12,13 +12,11 @@ :gotJavaHome if not exist "%JAVA_HOME%\bin\java.exe" goto noJavaHome if not exist "%JAVA_HOME%\bin\javaw.exe" goto noJavaHome -if not exist "%JAVA_HOME%\bin\jdb.exe" goto noJavaHome -if not exist "%JAVA_HOME%\bin\javac.exe" goto noJavaHome goto okJavaHome :noJavaHome echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program -echo NB: JAVA_HOME should point to a JDK not a JRE +echo NB: JAVA_HOME should point to a JDK or a JRE goto exit :okJavaHome @@ -55,3 +53,4 @@ exit /b 1 :end + Here is a patch for $CATALINA_HOME/bin/setclasspath.sh --- setclasspath.sh Fri Oct 29 20:13:00 2004 +++ setclasspath2.sh Fri Nov 5 12:22:55 2004 @@ -18,10 +18,10 @@ exit 1 fi else - if [ ! -x "$JAVA_HOME"/bin/java -o ! -x "$JAVA_HOME"/bin/jdb -o ! -x "$JAVA_HOME"/bin/javac ]; then + if [ ! -x "$JAVA_HOME"/bin/java ]; then echo "The JAVA_HOME environment variable is not defined correctly" echo "This environment variable is needed to run this program" - echo "NB: JAVA_HOME should point to a JDK not a JRE" + echo "NB: JAVA_HOME should point to a JDK or a JRE" exit 1 fi fi @@ -59,3 +59,4 @@ _RUNJDB="$JAVA_HOME"/bin/jdb fi _RUNJAVAC="$JAVA_HOME"/bin/javac +
I sort of agree with the bug report, but not really with the solution. AFAIK, most other programs which use JAVA_HOME expect a JDK, and some of the features of the scripts also use the JDK (ex: jdb). The fact that Tomcat fully works with the JRE is used for the Windows installer, and stuff like that, but in the scripts it is a problem IMO.
*** Bug 32669 has been marked as a duplicate of this bug. ***
>I sort of agree with the bug report, but not really with the solution. >AFAIK, most other programs which use JAVA_HOME expect a JDK, What about looking for JRE_HOME if JAVA_HOME is not found?
*** Bug 32793 has been marked as a duplicate of this bug. ***
Using a second JRE_HOME (initialized to JAVA_HOME if blank) for the "base" features of the scripts is indeed a possibility.
> Using a second JRE_HOME (initialized to JAVA_HOME if blank) for the > "base" features of the scripts is indeed a possibility. In the event that both are set, which should it prefer? If JRE_HOME, should it fail when the 'debug' arg is present, even if JAVA_HOME set? I've got rough drafts of the bash scripts running with the JRE on FC2 now.
Created attachment 13961 [details] update setclasspath.sh to run with JRE Tested on FC3
Created attachment 13962 [details] update catalina.sh to run with JRE Tested on FC3
I would like to resolve this issue in the next build (5.5.7). I have some questions: - [ -n "$JRE_HOME" ] && JAVA_HOME=`cygpath --unix "$JRE_HOME"` doesn't seem right to me; shouldn't it be [ -n "$JRE_HOME" ] && JRE_HOME=`cygpath --unix "$JRE_HOME"` ? - you attached the wrong diff for setclasspath.sh, can you fix it ? - can you remove the debug stuff from your catalina.sh patch ? ;)
Created attachment 13967 [details] Patches for catalina.sh and setclasspath.sh Yes to all questions and sorry about the sloppiness.
That looks good. Thanks. I'm adding back the #!/bin/sh at the beginning of catalina.sh, though. Any reason why it's removed ? I'm leaving the bug open for Windows, but I really don't care about the problem (most users of the batch scripts on Windows will be developers, which means they have the JDK).
> I'm adding back the #!/bin/sh at the beginning of catalina.sh, though. Any > reason why it's removed ? No, it should be there. > I'm leaving the bug open for Windows, but I really don't care about the problem > (most users of the batch scripts on Windows will be developers, which means they > have the JDK). I'll do the same for the batch scripts to keep them consistent with the shell scripts. Thank you -Ben
On starting the tomcat server the following error message is displayed "The system cannot find the file -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager."
Ben, any luck putting together the same type of patch for the Windows batch scripts? If you have it, I'll gladly look at / apply it. Las, besides not being able to reproduce what you're claiming, I'm not sure it's related to this specific Bugzilla issue. I'd try asking on the users@tomcat.apache.org list if I were you.
ported the patch to the win32 scripts
Just faced this problem today in the 5.5.14 release. When will this patch be added?
Look at the very first item on the 5.5.15 (not 5.5.14 ;)) change log.
*** Bug 38967 has been marked as a duplicate of this bug. ***
*** Bug 36663 has been marked as a duplicate of this bug. ***