Java ne démarre pas Listener Sous Tomcat

Question

Dans mes journaux Tomcat (catalina) Je reçois l'erreur suivante empêchant ma demande de démarrage:

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

Je ne sais pas pourquoi je reçois ce. Dans mon web.xml je les

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

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

Quand je commente les auditeurs, il démarre bien. Le code pour les listners sont ci-dessous:

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

et

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

Pourquoi ce ne démarre pas? Ou où puis-je trouver plus d'informations?

UPDATE

Il semble seulement être un problème avec SessionAttributeListener de démarrage. Le SessionListener ne commençait pas parce que le ont été déclarés après la balise

UPDATE

Il y avait un problème avec le fichier JAR utilisé. La classe pour SessionAttributeListener n'a pas été inclus. Quand il a été inclus l'application a commencé.

UPDATE

Le AttributeListener ne semble pas être en cours d'exécution. Quand il est utilisé le code échoue. Yat-il un moyen simple de vérifier si un écouteur est en cours d'exécution?

Answer 1

re votre mise à jour la lecture « Le AttributeListener ne semble pas être en cours d'exécution. Quand il est utilisé le code échoue. Yat-il un moyen simple de vérifier si un écouteur est en cours d'exécution? » Avez-vous essayé d'ajouter un statique initialiseur? quelque chose comme

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

de cette façon la première fois que la classe est référencé, vous devriez obtenir un enregistrement de journal.

Answer 2

Depuis que je fini par trouver ma route vers une solution ailleurs, je pensais que ce serait utile de mettre à jour cette question avec ces informations.

Il est tout à faire à l'exception sous-jacente qui provoque la redoutée. « GRAVES: Erreur listenerStart » un message ne pas être connecté partout, et comment configurer l'enregistrement pour produire l'exception

De ici il y a une description très claire de la question de l'exploitation forestière et une solution.

Dans mon cas, je suis allé pour une version encore plus réduire, en ajoutant

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

à la tomcat conf / logging.properties, et en remplaçant / web-app avec le chemin de contexte d'application web approprié.

Et comme par magie l'exception caché est apparu et m'a dit Java 6 Runtime ne voulait pas savoir sur le code compilé par Java 7. Embarrassant, mais facilement fixe.

Ceci est applicable à Tomcat 7. Votre kilométrage peut varier.

Answer 3

Lorsque vous rencontrez « démarrage échoué en raison d'erreurs précédentes » dans vos journaux de Tomcat, vous soit trouver une autre exception dans le journal qui est à l'origine de cette question ou si vous devez configurer entièrement l'exploitation forestière dans les Tomcat telles que l'exception peut-être écrit dans les journaux. Une fois que vous avez la cause racine écrite à vos journaux, la résolution est généralement trivial.