Comment faire pour que les filtres de servlet cessent de se charger au démarrage de l'application dans Tomcat?

Voici mon descripteur de déploiement. J'utilise Spring MVC, mais j'ai un filtre de réécriture d'url en place qui est supposé fonctionner, puis je l'envoie au contrôleur approprié. Pour une raison quelconque, ce filtre est en cours de chargement au démarrage, essayant d'obtenir le chemin traduit, et lançant une exception nullpointer car il n'y a pas de chemin. Je n'ai jamais su que les filtres étaient chargés au démarrage, mais cela ressemble à ce qui se passe.Comment faire pour que les filtres de servlet cessent de se charger au démarrage de l'application dans Tomcat?

<!-- SERVLETS --> 

<servlet> 
    <servlet-name>springmvc</servlet-name> 
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
    <load-on-startup>1</load-on-startup> 
</servlet> 

<servlet-mapping> 
    <servlet-name>springmvc</servlet-name> 
    <url-pattern>/index.html</url-pattern> 
</servlet-mapping> 

<servlet-mapping> 
    <servlet-name>springmvc</servlet-name> 
    <url-pattern>/</url-pattern> 
</servlet-mapping> 

<!-- FILTERS --> 

<filter> 
    <filter-name>URLRewriteFilter</filter-name> 
    <filter-class>com.ecomm.filters.URLRewriteFilter</filter-class> 
</filter> 

<filter-mapping> 
    <filter-name>URLRewriteFilter</filter-name> 
    <url-pattern>/*</url-pattern> 
</filter-mapping>

EDIT:

Aug 17, 2010 11:28:12 AM org.apache.catalina.core.StandardWrapperValve invoke 
SEVERE: Servlet.service() for servlet jsp threw exception 
java.lang.NullPointerException 
    at com.ecomm.helpers.TranslateURLHelper.executeController(TranslateURLHelper.java:47) 
    at com.ecomm.filters.URLRewriteFilter.doFilter(URLRewriteFilter.java:41) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) 
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) 
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879) 
    at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) 
    at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) 
    at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) 
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) 
    at java.lang.Thread.run(Unknown Source)

Source

2010-08-17 Anonymous

Il semble que vous déployez la webapp sur le contexte ROOT en utilisant Eclipse. Le plugin Tomcat d'Eclipse effectue en effet un autotest au démarrage en envoyant une requête GET sur la racine. Il suffit de l'ignorer ou de corriger le code pour qu'il ne lance pas NPE. C'est IMO certainement un bug dans le com.ecomm.filters.URLRewriteFilter. Les chemins vides ne doivent pas être considérés comme des cas exceptionnels. Les utilisateurs finaux pourraient les tirer aussi bien.

Source

2010-08-17 15:58:00 BalusC

Je suis en effet en cours d'exécution de l'application en tant que ROOT à travers Eclipse. Si cela ne vous dérange pas de poser une autre question, où avez-vous lu que Tomcat envoie une requête GET à ROOT au démarrage? Merci! –

C'est en fait le plugin Eclipse Tomcat qui fait cela. J'ai déjà observé ce comportement et je peux confirmer le comportement que vous voyez. – BalusC

Cela ne fait pas beaucoup de sens. Les filtres s'appliquent uniquement aux demandes. Êtes-vous sûr qu'il n'y a rien dans votre config de Spring qui entraîne 1) la classe de filtre invoquée ou 2) le déclenchement d'une requête http?

Que montre la trace de pile du NPE dans le filtre?

Je pense que vous aurez envie de comprendre d'où viennent ces demandes afin de comprendre comment résoudre le problème.

Source

2010-08-17 13:57:54

J'ai ajouté la pile. Il semble que Tomcat appelle la méthode doFilter(), mais je ne trouve nulle part un état indiquant qu'un filtre est chargé au démarrage au-delà de son initialisation. Mon code n'est pas dans le init(). Je peux certainement ajouter une condition autour de tout dans doFilter(), mais je voulais m'assurer qu'il n'y avait pas d'option de configuration avant de le faire. –

Je ne savais pas que les filtres chargés au démarrage ...

Je suppose que cela dépend de la façon dont vous définissez « chargé ». Une instance sera construite et sa méthode init(FilterConfig) invoquée avant même d'agir sur une requête, il y a donc quelques opportunités pour que son code s'exécute "au démarrage". Comme demandé, s'il vous plaît poster l'exception réelle ...

Source

2010-08-17 14:11:09 kschneid

Comment faire pour que les filtres de servlet cessent de se charger au démarrage de l'application dans Tomcat?

Répondre

Questions connexes