[jira] Commented: (WW-3026) Struts 2 needs to log errors in the processing of the struts.xml configuration file (suggested fix included).

["Musachy Barroso (JIRA)" <ji...@apache.org>]

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

Musachy Barroso commented on WW-3026:
-------------------------------------

Please provide some examples of errors that are not logged, so we can reproduce this problem.

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