[
https://issues.apache.org/jira/browse/WW-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759960#comment-13759960
]
Nicholas commented on WW-4191:
------------------------------
Haha, yes of course we want to give them a nice 404. Sorry by writing your own
I mean writing a whole unknown handler. Generally speaking we have a reverse
proxy that detects 404 status codes and returns a customized error page so its
standardized over our entire web stack.
The issue to me is more the convention with the level of logging when not on
dev mode. By convention struts now produces that as an error, when really a 404
is not an error when you get a whole heap of visitors that go crazy on your
site. In dev mode it makes sense for it to produce an error since it could
indicate an issue. In production though I can see it making sense (Unless you
have an extremely sensitive operation, in which case then you could implement
your own unknown handler).
> 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
