Bug 45585 - Tomcat doesn't start when JULI is not used (NoClassDefFoundError)
Summary: Tomcat doesn't start when JULI is not used (NoClassDefFoundError)
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.18
Hardware: All All
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 45968 45983 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-08-06 23:42 UTC by Rainer Jung
Modified: 2014-02-17 13:43 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Jung 2008-08-06 23:42:31 UTC
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.
Comment 1 Rainer Jung 2008-08-07 00:24:02 UTC
> 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. 
Comment 2 Mark Thomas 2008-08-08 09:02:01 UTC
I've committed the nop fix to trunk and proposed it for 6.0.x
Comment 3 Mark Thomas 2008-08-13 15:47:46 UTC
This has been applied to 6.0.x and will be included in 6.0.19 onwards.
Comment 4 Mark Thomas 2008-08-27 13:52:14 UTC
This has been applied to 5.5.x and will be included in 5.5.27 onwards.
Comment 5 Mark Thomas 2008-10-08 15:18:48 UTC
*** Bug 45968 has been marked as a duplicate of this bug. ***
Comment 6 Mark Thomas 2008-10-10 00:02:58 UTC
*** Bug 45983 has been marked as a duplicate of this bug. ***