You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Christian Wolfgang Stone (JIRA)" <ji...@apache.org> on 2009/03/08 06:28:02 UTC

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

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


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.


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

Posted by "Christian Wolfgang Stone (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/struts/browse/WW-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45832#action_45832 ] 

Christian Wolfgang Stone commented on WW-3026:
----------------------------------------------

Add this package to your struts.xml file...

    <package name="license" namespace="/license">
    <default-interceptor-ref name="guest"/>

    <default-action-ref name="index"/>
  
   <action name="index">
         <result type="freemarker">/license/index.ftl</result>
     </action>
    </package>

This should do it.  The default interceptor reference does not exist...

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


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

Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
     [ 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.


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

Posted by "Musachy Barroso (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Musachy Barroso updated WW-3026:
--------------------------------

    Fix Version/s: 2.1.7

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


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

Posted by "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.