Java Listener startet nicht unter Tomcat

Question

In meinen Tomcat-Protokollen (catalina) Ich erhalte die folgenden Fehler verhindern meine Anwendung von Start-up:

SEVERE: Error listenerStart
24-Mar-2009 13:23:10 org.apache.catalina.core.StandardContext start
SEVERE: Context [/exampleA] startup failed due to previous errors

Ich weiß nicht, warum ich dies immer. In meiner web.xml habe ich folgendes

<listener>
    <listener-class>
        uk.co.a.listener.SessionListener
    </listener-class>
</listener>

<listener>
    <listener-class>
        uk.co.a.listener.SessionAttributeListener
    </listener-class>
</listener>

Wenn ich die Zuhörer kommentieren Sie es startet in Ordnung. Der Code für die listners sind unter:

public class SessionAttributeListener implements HttpSessionAttributeListener {
    static Log log = LogFactory.getLog(SessionAttributeListener.class.getName());

    public void attributeAdded(HttpSessionBindingEvent hsbe) {
        log.debug("VALUE attributeAdded to THE SESSION:" + hsbe.getName());
    }

    public void attributeRemoved(HttpSessionBindingEvent hsbe) {
        log.debug("VALUE attributeRemoved from THE SESSION:" + hsbe.getName());
    }

    public void attributeReplaced(HttpSessionBindingEvent hsbe) {
        log.debug("VALUE attributeReplaced in THE SESSION:" + hsbe.getName());
    }
}

und

public class SessionListener implements HttpSessionListener {

    static Log log = LogFactory.getLog(SessionListener.class.getName());

    private static int activeSessions = 0;
    public void sessionCreated(HttpSessionEvent evt)
    {
        activeSessions++;
        log.debug("No. of active sessions on:"+
                new java.util.Date()+" : "+activeSessions);
    }
    public void sessionDestroyed (HttpSessionEvent evt)
    {
        activeSessions--;
    }
} 

Warum beginnt das nicht? Oder wo kann ich nach mehr Informationen?

UPDATE

Es scheint nur von Start-up ein Problem mit SessionAttributeListener zu sein. Die SessionListener wurde nicht an den Start, weil der nach dem deklariert wurden

UPDATE

Es gab ein Problem mit der JAR-Datei verwendet. Die Klasse für SessionAttributeListener wurde nicht berücksichtigt. Als es begann die Anwendung enthalten.

UPDATE

Die AttributeListener scheint nicht zu laufen. Wenn es verwendet wird, der Code fehlschlägt. Gibt es eine einfache Möglichkeit zu überprüfen, wenn ein Listener ausgeführt wird?

Answer 1

re Ihr Update zu lesen „Die AttributeListener nicht zu sein scheinen ausgeführt wird. Wenn es verwendet wird, der Code nicht. Gibt es eine einfache Möglichkeit zu überprüfen, ob ein Zuhörer läuft?“ Sie haben versucht, eine statische initialiser hinzufügen? so etwas wie

static {
log.debug("static initialiser called");
}

auf diese Weise das erste Mal, dass die Klasse verwiesen wird, sollten Sie einen Protokolldatensatz erhalten.

Answer 2

Da ich meine Route zu einer Lösung an anderer Stelle gelandet zu finden, dachte ich, es wäre nützlich, mit diesen Informationen um dieses Problem zu aktualisieren.

Es ist alles mit der zugrunde liegenden Ausnahme zu tun, die die gefürchtete verursacht. ‚SCHWERE: Fehler listenerStart‘ Nachricht überall wird nicht protokolliert, und wie die Protokollierung konfigurieren, um die Ausnahme zu erzeugen

hier gibt es eine sehr klare Beschreibung des Holzeinschlags und eine Lösung.

In meinem Fall ging ich für eine noch abgespeckte Version, das Hinzufügen

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/web-app].level = FINE
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/web-app].handlers = java.util.logging.ConsoleHandler

Zum Kater conf / logging.properties und Ersetzen / web-app mit dem entsprechenden Web-Anwendung Kontextpfad.

Und auf magische Weise die verborgene Ausnahme erschien und sagte mir, die Java 6 Runtime wollte nicht von Java 7. Peinlicher kompiliert über Code kennen, aber leicht behoben.

Dies ist für Tomcat 7. Ihre Leistung kann variieren.

Answer 3

Wenn Sie stoßen „failed Inbetriebnahme aufgrund früherer Fehler“ in Ihrem Tomcat-Protokolle, werden Sie entweder eine Ausnahme finden weiter oben im Protokoll, das dieses Problem verursacht, oder Sie müssen vollständig Protokollierung innerhalb Tomcat konfigurieren, dass die Ausnahme sein kann in die Protokolle geschrieben. Sobald Sie die Ursache geschrieben Ihre Protokolle haben, die Auflösung ist in der Regel trivial.