If there is no file CATALINA_BASE/conf/logging.properties, then Tomcat will not start and the JVM outputs the following error: Exception in thread "main" java.lang.NoClassDefFoundError: without any additional information. Quoting from a user's mail: I believe commit 652629 (which appeared in 6.0.17) broke catalina.sh startup when JULI is not used -- that is, when $CATALINA_BASE/conf/logging.properties does not exist. If this file is absent, LOGGING_CONFIG is not set. However the variable appears quoted in the shell command to exec the JVM: "$_RUNJAVA" $JAVA_OPTS "$LOGGING_CONFIG" $CATALINA_OPTS ... Which introduces an empty argument when LOGGING_CONFIG is unset, and the JVM interprets this empty argument as the class to be invoked. Three possible fixes are: * Set LOGGING_CONFIG to a harmless flag if JULI is not used. With my Sun JVM, a plain -D is safe. I don't know how portable this is. It isn't very pretty. * Maintain separate JVM invocations for the cases when LOGGING_CONFIG is set and when it's unset. This involves more code duplication. The code in question is already duplicated; I'm not sure whether that argues for or against this strategy. * Use a one-item shell array with an @ subscript, which is immune to word splitting when between double quotes but expands to nothing when unpopulated. For example: LOGGING_CONFIG[0]="-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties" followed by: "$_RUNJAVA" $JAVA_OPTS "${LOGGING_CONFIG[@]}" $CATALINA_OPTS ... This method may be too clever. I think POSIX requires shell arrays but being portable to true Bourne shell would require $@, which is already being used.
> We were already thinking about your first two solutions, I missed the third one. We'll need to check how reliable that is (w.r.t. POSIX). I am a little in favor of "-Dnop" or something similar. Yeah, a nop flag is probably more robust. If you end up using that, you might want to swap the order of $JAVA_OPTS and "$LOGGING_CONFIG", so that users who need whatever property name you pick (for whatever bizarre reason) can override the null setting with JAVA_OPTS.
I've committed the nop fix to trunk and proposed it for 6.0.x
This has been applied to 6.0.x and will be included in 6.0.19 onwards.
This has been applied to 5.5.x and will be included in 5.5.27 onwards.
*** Bug 45968 has been marked as a duplicate of this bug. ***
*** Bug 45983 has been marked as a duplicate of this bug. ***