Domanda

Nel mio log Tomcat (Catalina) sto ottenendo il seguente errore evitando la mia domanda di avviarsi:

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

Non so perché sto ottenendo questo. Nel mio web.xml ho il seguente

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

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

Quando io commento gli ascoltatori si avvia bene. Il codice per le listners sono al di sotto:

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());
    }
}

e

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--;
    }
} 

Perché questo non si avvia? O dove posso cercare ulteriori informazioni?

Aggiorna

Non solo sembra essere un problema con SessionAttributeListener di avviarsi. La SessionListener non è stato in fase di avvio, perché il sono stati dichiarati dopo il

Aggiorna

C'è stato un problema con il file JAR utilizzato. La classe per SessionAttributeListener non era inclusa. Quando è stato incluso l'applicazione è stata avviata.

Aggiorna

L'AttributeListener non sembra essere in esecuzione. Quando viene utilizzato il codice non riesce. C'è un modo semplice per verificare se un ascoltatore è in esecuzione?

È stato utile?

Soluzione

re l'aggiornamento a leggere "L'AttributeListener non sembra essere in esecuzione. Quando si utilizza il codice non riesce. C'è un modo semplice per verificare se un ascoltatore è in esecuzione?" hai provato ad aggiungere un initialiser statica? qualcosa come

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

in questo modo la prima volta che la classe si fa riferimento si dovrebbe ottenere un record di log.

Altri suggerimenti

Da quando ho finito per trovare la mia strada per una soluzione altrove, ho pensato che sarebbe stato utile per aggiornare la questione con queste informazioni.

E 'tutto a che fare con l'eccezione sottostante che provoca la temuta. 'SEVERE: Errore listenerStart' messaggio non viene registrato da nessuna parte, e come configurare la registrazione per produrre l'eccezione

href="http://www.java-tutorial.ch/java-server-faces/jsf-error-listener-start-error-using-tomcat" qui v'è una chiara descrizione del problema registrazione e una soluzione.

Nel mio caso io siamo andati per una versione ancora più abbattuto, aggiungendo

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

per Tomcat conf / logging.properties, e la sostituzione / web-app con il percorso del contesto dell'applicazione Web appropriato.

E magicamente l'eccezione nascosto è apparso e mi ha detto il runtime Java 6 non voleva sapere di codice compilato da Java 7. Imbarazzante, ma facilmente risolto.

Questo è valido per Tomcat 7. La vostra situazione potrebbe essere diversa.

Quando si incontra "Avvio non riuscito a causa di precedenti errori" nei log Tomcat, si sia trovare un'eccezione più in alto nel registro che causa questo problema oppure è necessario configurare pienamente la registrazione all'interno di Tomcat in modo tale che l'eccezione può essere da scrivere nei log. Una volta che hai la causa principale scritto al vostro log, la risoluzione è di solito banale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top