struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WW-4191) Excessive 404 error logging
Date Fri, 06 Sep 2013 05:02:52 GMT

    [ 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

Mime
View raw message