Announcement Announcement Module
No announcement yet.
SEVERE: Error listenerStart - finding the error Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • SEVERE: Error listenerStart - finding the error

    I often think about adding little bits of information as I learn more. Then after a while the information seems trivial - obviously since I've learned it and I can no longer remember the key fact that is needed to pass on. However, this is one I have to pass on. Maybe most of you already know this but I;m sure some won't!

    Ever get the SEVERE: Error listenerStart and can't find the error? Logs don't seem to help since this is a container start up problem.

    use a plugin
    I'm using tomcat - and whilst I understand Jetty is meant to be good for development, it doesn't seem to yet support eclipse 3.2. You probably have a script to start and restart tomcat or using a plugin to restart it. I'm using sysdeo ( which seemed to me to be the most common. With the sysdeo plug in I can start my tomcat in eclipse which can link in to the debugger.

    attach the source
    in your build path (project properties, java build path) select the libraries tab and the spring jar. Expand the + and click on source attachemtent, and edit the path to be the spring source 'src' directory.

    breakpoint ContextLoaderListener
    in the spring jar on the build path, find org.springframework.web.context and the ContextLoaderListener class. Set a breakpoint at line 49, which will read this.contextLoader.initWebApplicationContext(event .getServletContext());

    find the error!
    Now when you start tomcat from within an eclipe plugin it will stop at the above. Choose to 'step return' once and then wait for the container to load everything up and find an error. If there is an error you will now be at standardcontext.listenerstart and you can now look at the error in the variable window under 't'. There are 'cause' error, make sure you take a look at them all since some can be wrapped/hidden. If you're using hibernate, I find that this does show the hbm mapping file problems, but the actual bean which causes the error can be wrong - it seems to just take the first bean in its list!

    Good luck. Hopefully I and others will no longer spend a day wasting time scanning for errors!


  • #2
    As far as I know you get the same information from the stack trace that is logged when an error occurs on startup. Sometimes they are a bit on the opaque side (all the "caused by" referred to above), but they will all be there. All you need to do to see the stack trace is enable logging at the right level, e.g. by putting a in WEB-INF/classes.


    • #3
      Thanks David for the tip. I'll look at it again next time something 'SEVERE' happens.

      When things go wrong I backtrack over all outputs I have. The plugin appears to not perform the logging so when an error stumps me I go back to the grass roots of manually starting and stopping the server and enable everything like logging, then look at as many outputs as possible. I find that the logs don't output the stack trace.

      Perhaps its my setup? Perhaps I'm not looking as hard as you suggest? At least I have found a way forward for me, and it will be useful to others to find this thread to show them the possible options.

      The log4j file is below - but in a slightly different place (as indicated here by the web.xml file).


      log4j.rootLogger=INFO, logfile

      # in case any output is given to stdout, format it
      log4j.appender.stdout=org.apache.log4j.ConsoleAppe nder
      log4j.appender.stdout.layout=org.apache.log4j.Patt ernLayout
      log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n

      log4j.appender.logfile=org.apache.log4j.RollingFil eAppender
      # Keep three backup files.
      # Pattern to output: date priority [category] - message
      log4j.appender.logfile.layout=org.apache.log4j.Pat ternLayout
      log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n editors.CustomDateEditor=DEBUG


      # showing sql torImpl=DEBUG er=DEBUG


      • #4
        ah - ha

        Well its SevereError again...and having problems because its a remote server (and can't remote debug until its started up!) - and don't get any messages.

        But I just stumbled across a hint...and it WORKS. Obvious really. Not sure why I haven't come across this before, but the reason I wans't getting any output before the error was that my log4j configuration was not listed ABOVE the ContextLoaderListener listener definition!



        • #5
          If you are using tomcat then uncomment this

          <listener-class>org.springframework.web.util.Log4jConfigList ener</listener-class>

          in your web.xml.

          It works in my case.



          • #6
            I have had this problem with Spring + Tomcat for years. I NEVER get a stack trace. Trust me, I've looked through every log file in the $CATALINA_HOME/logs directory. All that prints out is the following:

            Jun 10, 2008 4:54:30 PM org.apache.catalina.core.StandardContext start
            SEVERE: Error listenerStart
            Jun 10, 2008 4:54:30 PM org.apache.catalina.core.StandardContext start
            SEVERE: Context [] startup failed due to previous errors

            And yes, I have Log4jConfigListener in my web.xml (the first listener before ContextLoaderListener). I also have my default logging level in log4j.xml set to DEBUG, log4j.jar is in the classpath, etc.

            This occurs anytime there is an error initializing the Spring context. It is the biggest pain to deal with. I used to use JBoss and never experienced this issue, so it's definitely a problem with using Tomcat with Spring (and presumably commons-logging/log4j)

            The ONLY way I know how to even discover the cause exception is to debug the ContextLoaderListener. It seems like there HAS to be a way to get the stack trace to print out, but after spending many hours on this issue I've never found one.

            If anyone knows how to make Tomcat print out the stacktrace to the log files, please let me know.


            • #7

              After 2 hours of trying to solve this...i stumble upon this post lol, I hope the programming gods grant me a solution to figuring out this contextListerning issue..
              im sure it is something simple..but having no debug trace is making it hard..


              • #8
                That's always been my result when encountering this problem. Usually the problem is something simple, but I waste hours on it because there is no way to get a stacktrace to tell you what the problem is.

                This may be an issue with Tomcat, but it's pretty common to encounter it with Spring, since Spring's ApplicationContext starts up in a listener. If any exceptions occur while initializing the context, you get the vague "listenerStart" error message with no additional details...


                • #9

                  Only way to effectively find your error is to do what adam_jh suggested!
                  debugging using Sysdeo !...happy coding.


                  • #10
                    As I mentioned in my first post here, my Log4j configuration IS listed above ContextLoaderListener, so that doesn't always work.


                    • #11
                      When you set a break point, when the ContextListener gets an error, do you see the exceptions being thrown and Message?( use the eclipse debug mode..)...


                      • #12
                        Yes, I can see it in the debugger, but you would think there should be SOME way to display the stack trace in the logs.


                        • #13
                          I added the breakpoints after getting this error....I had to update the context definition for the breakpoints to kick in. After that the error disappeared.

                          thanks for the tip tho!


                          • #14
                            If anyone is still being stung by this, I found that the errors were output to $CATALINA_BASE/logs/localhost-YYYY-mm-dd.log (subtituting the actual date in the filename, of course).


                            • #15
                              Thank you kindly for this sir. As a complete Spring Chicken (1 week in) This helped immensely. It would have taken a couple of eyes to see a syntax error in my applicationContext.xml file that this debugging session manifested

                              Thanks for the help, again! great plugin find, as well!