struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (WW-3026) Struts 2 needs to log errors in the processing of the struts.xml configuration file (suggested fix included).
Date Thu, 02 Apr 2009 19:48:06 GMT

     [ https://issues.apache.org/struts/browse/WW-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Musachy Barroso resolved WW-3026.
---------------------------------

    Resolution: Fixed

try/cath added to Dispatcher.init to log exceptions and rethrow them

> Struts 2 needs to log errors in the processing of the struts.xml configuration file (suggested
fix included).
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WW-3026
>                 URL: https://issues.apache.org/struts/browse/WW-3026
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Actions, Core Interceptors
>    Affects Versions: 2.1.6
>         Environment: Struts core.
>            Reporter: Christian Wolfgang Stone
>             Fix For: 2.1.7
>
>
> I have logged a few suggested spots to log errors with the struts.xml configuration processing.
 A number of times people have complained that struts does not do enough to log errors with
request or configuration processing.  I believe this is really affecting the adoption of struts
2.  Currently, if there is a typo or misconfigured action in the struts 2 config, errors are
not logged (not even in with logging set to debug).  You only know that the context will not
start because errors prevented it from doing so.  My solution is to report when an action
is misconfigured.  There are a couple of spots that I suggest based on my own debugging of
the code.
> org.apache.struts2.dispatcher.filterDispatcher (line 194)
>    public void init(FilterConfig filterConfig) throws ServletException {
>         try {
>             this.filterConfig = filterConfig;
>             initLogging();
>             dispatcher = createDispatcher(filterConfig);
>             dispatcher.init();
>             dispatcher.getContainer().inject(this);
>             staticResourceLoader.setHostConfig(new FilterHostConfig(filterConfig));
>         } finally {
>             ActionContext.setContext(null);
>         }
>     }
> +++++ add catch clause before final (will log a message like - "Unable to find interceptor
class referenced by ref-name admin - interceptor-ref - file:/source/websites/mdff/trunk/build/exploded/WEB-INF/classes/struts-admin-member.xml:107:44"
 This message is EXTREMELY HELPFUL :)
> } catch (ConfigurationException e) {
>       LOG.error("Processing of struts2 configuration failed.  Reason: "+e.toString(),e);
> }
> ++++
> -or- in com.opensymphony.xwork2.config.ConfigurationManager.java line 57
>     public synchronized Configuration getConfiguration() {
>         if (configuration == null) {
>             setConfiguration(new DefaultConfiguration(defaultFrameworkBeanName));
>             try {
>                 configuration.reloadContainer(getContainerProviders());
>             } catch (ConfigurationException e) {
>                 setConfiguration(null);
>                 throw new ConfigurationException("Unable to load configuration.", e);
>             }
>         } else {
>             conditionalReload();
>         }
>         return configuration;
>     }
> ++++ add LOG error before killing the configuration file!  Obviously 
> LOG.error("Unable to load configuration."+e.toString(),e);
> ===
> I am sure there are other places.  Anyone needing to do a bunch of work with a large
configuration file -- I have about 200 actions, and am regularly moving actions from one file
to the next and sharing the files between projects (using spring to override the action classes)
-- will deeply appreciate this change.  Nothing is more depressing than to suddenly have 0
notifications as to why the context won't load knowing that you are including many many changes
and knowing that somewhere in one package the name of the interceptor-ref was changed from
admin to adminStack, and another files action inheriting this package still refers to the
old name!
> By the way... if you want another developer I may be able to put some time in...
> Otherwise, I thank you all for this tool.  It really has made my work better...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message