How can I find the error when Tomcat fails to start my Spring/Hibernate web application?

Question

I have a Spring/Hibernate application which I have converted into a web application in order to provide RESTful web services (using Jersey). I am trying to deploy the web application onto Tomcat 6.0.20 and I get only a cryptic error message in the log file:

Jul 8, 2009 2:25:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Jul 8, 2009 2:25:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/lmrest] startup failed due to previous errors

I have set my logging level to debug but there are no suspicious messages which show what went awry, other than this one, which looks pretty innocuous to me:

1360 [http-8080-1] INFO  org.hibernate.cfg.search.HibernateSearchEventListenerRegister  - Unable to find org.hibernate.search.event.FullTextIndexEventListener on the classpath. Hibernate Search is not enabled.

I am using the latest versions of Spring and Hibernate. I am using a ContextLoaderListener in my web.xml. Could this be the listener that is failing to start? I assume it is running at least partially since I can see many Hibernate configuration log messages scroll past before the failure of the start of the web app. My main trouble is I can't see any error messages indicating what has failed to start the listener it's complaining about.

The web.xml I'm using looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
                   http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

    <!-- listener to pull in the Spring application context -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:appContext.xml</param-value>
    </context-param>

    <!-- Jersey servlet container to intercept all URIs -->
    <servlet>
        <servlet-name>JerseyContainer</servlet-name>
        <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>JerseyContainer</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

If anyone can give me some ideas as to where to look for my error I'll really appreciate it, as I'm stumped. Thanks in advance!

--James

Solution 1

Please do the following:

• remove all log4j related artifacts from your war file - includes log4j.jar/properties/xml;
• include log4j.jar in common/lib or lib ( depending on your Tomcat version );
• add a log4j.properties file in common/classes ( not sure on Tomcat 6 ).

This config should make sure that all log4j output is properly directed. Switch to debug if needed, but it should not be:

log4j.rootLogger=info, R 

log4j.appender.R=org.apache.log4j.RollingFileAppender 
log4j.appender.R.File=${catalina.home}/logs/catalina.out 
log4j.appender.R.MaxFileSize=10MB 
log4j.appender.R.MaxBackupIndex=10 
log4j.appender.R.layout=org.apache.log4j.PatternLayout 
log4j.appender.R.layout.ConversionPattern=%d %p %t %c - %m%n 

Solution 2

Under ubuntu 12.04, tomcat7 system logs are stored in /var/lib/tomcat7/localhost.<date>.log

This location is controlled by /etc/tomcat7/logging.properties:

handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.

2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler

Since startup failed due to a Tomcat error, not an application error, this is where the detailed report ended up. In my case Tomcat was complaining about a missing class definition.

SEVERE: Error configuring application listener of class com.foo.security.tomcat.CustomSessionListener
java.lang.ClassNotFoundException: com.alleni.zebra.security.tomcat.CustomSessionListener

Solution 3

Check your log4j.properties or log4j.xml and make sure your logging level is set to DEBUG

Solution 4

Apache can't find class org.hibernate.cfg.search.HibernateSearchEventListenerRegister. Are you sure that all classes needed to start hibernate are loaded in classpath? Hibernate is divided into many .jar package, I suggest you to check dependencies beetween files .jar

View more solutions

Comments

[lumpynose]

And if you were using maven you wouldn't need to do much for managing the dependencies since that's one of the things maven is famous for.

[James Adams]

Yes, I am using Maven. It's curious that this Spring application context starts up fine when I run it at the command line (packaged as a JAR) but when it's deployed in Tomcat (packaged as a WAR) it fails at some point. If the application context is valid when called from within a main class, via 'new ClassPathXmlApplicationContext("appContext.xml")' then shouldn't it behave the same when it's started by Tomcat via the ContextLoaderListener and a contextConfigLocation parameter which uses the same exact application context XML?

[James Adams]

Maybe there's some difference between how Maven organizes classes in JAR and WAR artifacts which is causing this issue? I am using the shade plugin in order to include all dependency JARs in the final artifact, and when I package the application as a JAR I see the actual class files of the dependencies included in the JAR whereas when I package the application as a WAR I instead see the dependency JARs included under WEB-INF/lib. Is it possible that this is causing some sort of ill effect? Am I assuming too much thinking that my orig app context XML file should work just as well in Tomcat?

[James Adams]

Yes, as stated above I have done this, but unfortunately there is no error to be seen other than the previously mentioned INFO message which indicates that the FullTextIndexEventListener class can't be found on the classpath. However in the WAR I can see the following Hibernate JARs in WEB-INF/lib: hibernate-3.2.6.ga.jar hibernate-annotations-3.4.0.GA.jar hibernate-commons-annotations-3.1.0.GA.jar hibernate-core-3.3.0.SP1.jar hibernate-validator-3.0.0.ga.jar

[James Adams]

It's interesting that when I search for the FullTextIndexEventListener class I find it in hibernate-annotations-3.2.1.ga.jar, but in my pom.xml (and in the resulting WAR artifact) I have a later version of that dependency (version 3.4.0.GA). Maybe there's some backwards compatibility issues, i.e. that class is no longer present in the newer version?

[James Adams]

Unfortunately that's the only thing that jumps out as an error, even though it's listed as an INFO level log message. Almost all of the DEBUG messages involve Hibernate annotation binding, all of which appear to be reporting a successful operation.

[Brian Clozel]

this one worked for me. At least it helps you to find the real cause! Thanks Robert!

[Don Branson]

thank you, thank you. I was pulling my hair out on this one.