On Java, Python, Groovy, Grails, Spring, Node.js, Linux, Arduino, ARM, Embedded Devices & Web

  • Recent Posts

    August 2017
    M T W T F S S
    « Jul    
  • Subscribe Options

  • Awards

  • Most Valuable Blogger @ DZone
  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 172 other followers

  • Follow MyThinkPond on
  • Blog Stats

    • 364,737 hits
  • General Options

Archive for the ‘Tomcat’ Category

Not all Tomcat 6 classloaders must be equal

Posted by Venkatt Guhesan on July 1, 2011

Today, while doing some Grails development I came across a peculiar issue that perplexed me and I’m documenting it for all others to benefit. (Also see my other blog from today for the issue that started this journey).

Here are my specifications:

Development Machine

  • Windows-7, 64-bit
  • java version “1.6.0_24”
    Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
    Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
  • Grails 1.4.0.M1
  • Tomcat – apache-tomcat64-6.0.32

Local Deployment Server

  • Windows Vista, 32-bit
  • java version “1.6.0_26”
    Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
    Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
  • Grails (does not matter since I’ll be deploying a WAR)
  • Tomcat – apache-tomcat-6.0.32 (32-bit version of Tomcat)

Since the issue we are taking about deals with Grails, let’s get into he details of how I ended up with the WAR. In Grails, I issued the following command:

>grails war abcdefg.war

This creates a war file. When deployed under the 64-bit Tomcat, no issues. But when deployed under the 32-bit Tomcat. I was getting the

Jul 1, 2011 10:08:25 AM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart

(See my previous article on how I enabled debugging to get to the root cause of the issue.)

But after some debugging, what it boiled down to was a “Class Cannot Be Found” error:

Jul 1, 2011 11:29:25 AM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Error configuring application listener of class org.codehaus.groovy.grails.web.util.Log4jConfigListener
java.lang.ClassNotFoundException: org.codehaus.groovy.grails.web.util.Log4jConfigListener

In examining the war file, the JAR file named “grails-web-1.4.0.M1.jar” under the “/WEB-INF/lib” does not contain the needed “Log4jConfigListener” class under “grails-web-1.4.0.M1.jar\org\codehaus\groovy\grails\web\util\”

But clearly this class is inside this other JAR file named “grails-plugin-logging-1.4.0.M1.jar” under “\org\codehaus\groovy\grails\web\util\”.

And this identical war file works under the 64-bit Tomcat but not under the 32-bit Tomcat.

So how did I resolve the issue? I upgraded my 32-bit box to Tomcat 7.0 and this made it work. But clearly, there is an underlying issue with the class-loader under the 32-bit Tomcat 6.0.32.

Maybe someone reading this will have the answer to this issue.


Posted in Grails, Groovy, Java, Tomcat, web development | Tagged: , , , , | Leave a Comment »

Tomcat 6+: Infamous “SEVERE: Error listenerStart” message – How-To debug this error?

Posted by Venkatt Guhesan on July 1, 2011

I’m sure if you have been developing with Java and Tomcat for sometime, you are likely to run into the infamous debug error.

SEVERE: Error listenerStart

You will most likely start Googling it trying to find out what the heck is going on. And in trying to see the extended logging on what that “listenerStart” error means. After some lucky searches, you will see links asking you to drop a “” file under ‘/WEB-INF/classes’ directory inside your WAR to help debug which one of the listeners is throwing this crazy error.

Well, this advise will most likely work for you if you are developing under an earlier version of Tomcat. If you are using versions 6.0 or above then continue to read on…

In Tomcat 6 or above, the default logger is the”java.util.logging” logger and not Log4J. So if you are trying to add a “” file – this will NOT work. The Java utils logger looks for a file called “” as stated here:

So to get to the debugging details create a “” file under your”/WEB-INF/classes” folder of your WAR and you’re all set.

And now when you restart your Tomcat, you will see all of your debugging in it’s full glory!!!

Sample file:

org.apache.catalina.core.ContainerBase.[Catalina].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler

and you will most likely see a “class-not-found” exception. 😉

Look at the bright side, you’re now one step closer to the solution.

Happy coding!

Posted in Grails, Groovy, GWT, Java, Spring, Spring Framework, Tomcat, web development | Tagged: , , , , , | 25 Comments »

Understanding Tomcat Configuration

Posted by Venkatt Guhesan on December 22, 2010

Case #1:
When the Tomcat config is this:

<Host name="localhost" appBase="C:/apps/apache-tomcat/null"
       unpackWARs="true" autoDeploy="true"
       xmlValidation="false" xmlNamespaceAware="false">
<Context path="/" docBase="C:/apps/apache-tomcat/DeployedApps/HelloWorld" debug="0" reloadable="false" crossContext="false"/>

Observe the “path” element in the “Context”. Then…
http://localhost/index.jsp yields to the “index.jsp” under HelloWorld folder.
http://localhost/HelloWorld/index.jsp yields to a “404 Page”.

Case #2:
When the Tomcat setup is this:

<Host name="localhost" appBase="C:/apps/apache-tomcat/null"
       unpackWARs="true" autoDeploy="true"
       xmlValidation="false" xmlNamespaceAware="false">
<Context path="/HelloWorld" docBase="C:/apps/apache-tomcat/DeployedApps/HelloWorld" debug="0" reloadable="false" crossContext="false"/>

Once again observe the “path” element in the “Context”. Then…
http://localhost/index.jsp yields to a “blank page”.
http://localhost/HelloWorld/index.jsp yields to a “blank page”.
http://localhost/hw/index.jsp yields to the “index.jsp”.

So if the objective is to deliver “HelloWorld” as the default application for the root context, then the configuration for that instance should like “case #1”. If the objective of a particular application to be bound to a “path”=”application context”, then we need to deploy that instance as “case #2”.

I hope this clarifies the two models. Also note that in either one of these cases, I have modified the “Host” parameter’s “appBase” to point to a non-default folder (Default folder is “webapps” under TOMCAT_HOME. Depending upon the download you fetch, you may have additional applications such as the Tomcat manager and ROOT deployed by default each and every time. You do not need them unless you are using the Tomcat manager for your deployment. So in this example, I have move the “appBase” to point to an empty folder location.

Posted in Java, Tomcat | Tagged: , | Leave a Comment »