Return-Path: X-Original-To: apmail-struts-issues-archive@minotaur.apache.org Delivered-To: apmail-struts-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AF9B210B06 for ; Fri, 6 Sep 2013 06:17:53 +0000 (UTC) Received: (qmail 53613 invoked by uid 500); 6 Sep 2013 06:17:53 -0000 Delivered-To: apmail-struts-issues-archive@struts.apache.org Received: (qmail 53578 invoked by uid 500); 6 Sep 2013 06:17:53 -0000 Mailing-List: contact issues-help@struts.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@struts.apache.org Delivered-To: mailing list issues@struts.apache.org Received: (qmail 53531 invoked by uid 99); 6 Sep 2013 06:17:53 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Sep 2013 06:17:53 +0000 Date: Fri, 6 Sep 2013 06:17:52 +0000 (UTC) From: "Lukasz Lenart (JIRA)" To: issues@struts.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (WW-4191) Excessive 404 error logging MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/WW-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759975#comment-13759975 ] Lukasz Lenart edited comment on WW-4191 at 9/6/13 6:16 AM: ----------------------------------------------------------- The warn was introduced with WW-2874 - so maybe it makes sense to keep it as is. was (Author: lukaszlenart): The warn was introduced with WW-2874 - so maybe it makes sense. > Excessive 404 error logging > --------------------------- > > Key: WW-4191 > URL: https://issues.apache.org/jira/browse/WW-4191 > Project: Struts 2 > Issue Type: Bug > Components: Dispatch Filter > Affects Versions: 2.3.15.1 > Environment: Redhat Linux, tomcat 6, Sun JDK 1.6 > Reporter: Nicholas > Assignee: Lukasz Lenart > Priority: Minor > Labels: logging > > During a recent struts upgrade that we did for security purposes we started receiving large amounts of error logging when a visitor uses a URL that doesn't have an associated action mapping (like a 404). This happens when debug mode is disabled. > I believe the problem started when this JIRA ticket was 'fixed': > https://issues.apache.org/jira/browse/WW-3609 > I think the two commits giving us grief are: > http://svn.apache.org/viewvc?view=revision&revision=1396976 > http://svn.apache.org/viewvc?view=revision&revision=1397027 > The error I'm receiving is: > {noformat} > ERROR org.apache.struts2.dispatcher.Dispatcher - Exception occurred during processing request: There is no Action mapped for namespace [/package] and action name [missingactionname] associated with context path [/app]. > There is no Action mapped for namespace [/package] and action name [missingactionname] associated with context path [/app]. - [unknown location] > at com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:185) > at org.apache.struts2.impl.StrutsActionProxy.prepare(StrutsActionProxy.java:63) > at org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:39) > at com.opensymphony.xwork2.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:58) > at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:553) > at org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:77) > at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129) > at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:394) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:347) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861) > at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) > at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584) > at java.lang.Thread.run(Thread.java:619) > {noformat} > For the moment we've simply set the log level for the effected class to none to get around this but I don't think this is the optimal solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira