Mailing-List: contact issues-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@struts.apache.org
Date: Fri, 6 Sep 2013 05:02:52 +0000 (UTC)
From: "Nicholas (JIRA)" <jira@apache.org>
To: issues@struts.apache.org
Message-ID: <JIRA.12667230.1378427419649.89890.1378443772036@arcas>
In-Reply-To: <JIRA.12667230.1378427419649@arcas>
References: <JIRA.12667230.1378427419649@arcas>
Subject: [jira] [Commented] (WW-4191) Excessive 404 error logging
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/WW-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759867#comment-13759867 ] 

Nicholas commented on WW-4191:
------------------------------

I have used the unknown handler management for more complex scenarios such as managing resources from a CMS that were hosted on an external provider that are referenced relatively. Surely straight out of the box struts shouldn't be producing exceptions for something that really is not an exceptional case? It seems extremely overkill to have to write your own especially when its producing a 404 output already (99% of what a web application wants to do).

The 'solution' is more of a work around for a fix that was put into place for a ticket that was supposed to be in dev mode only anyway. Our applications have been running with more or less the same setup since early webwork days...

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