You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Jim Cushing (JIRA)" <ji...@apache.org> on 2007/08/29 16:22:34 UTC

[jira] Commented: (WW-2016) Zero-configuration ignores interceptor configuration

    [ https://issues.apache.org/struts/browse/WW-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42059 ] 

Jim Cushing commented on WW-2016:
---------------------------------

A follow up to my previous comment: It appears you must include the annotation on each action class. Putting it on a super class (e.g., BaseAction) does not apply it to subclasses.

> Zero-configuration ignores interceptor configuration
> ----------------------------------------------------
>
>                 Key: WW-2016
>                 URL: https://issues.apache.org/struts/browse/WW-2016
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 2.0.8
>         Environment: Windows XP, Tomcat 5.5.23 
>            Reporter: Sean McRae
>             Fix For: Future
>
>
> So I am using the GWT plug-in (http://code.google.com/p/struts2gwtplugin/) to integrate some new GWT work into our existing Struts app. In switching to Struts 2 we now would like to use the zero-config option and call all of our actions using this plug-in - basically an interceptor. Unfortunately we cannot call our actions, all named *Action, using this method as the zero-config method and Struts' discovery of actions and the assignment of interceptors seems to ignore the default interceptor setup (I tried redefining this in struts-default.xml - see below) or by specifying a default interceptor.
> It seems to me that Struts should do one of the following:
> 1) Use the defaultStack as defined (or overridden) in struts.properties and struts-default.xml
> 2) Define a stack that could be overridden in struts.xml
> 3) Provide some other mechanism to allow the developer to override the default zero-config interceptor stack
> Issue WW-1796 addresses this in some respect, but what I would like is to define the default interceptor stack and then used the WW-1796 feature to override that if I need to.
> Below are thing I tried to work around this issue.
> 1. Not deriving my package from gwt-default and struts-default so as not to get the defaultStack interceptor stack defined in struts-default.xml. I didn't really think this would work since the action classes aren't part of the any defined package but I thought I would try. So my package definition looked like this:
>     <package name="myPackage">
>         <interceptors>
>             <interceptor name="gwt"
>                 class="com.pharmanet.server.struts2.GWTInterceptor" />
>  
>             <interceptor-stack name="gwtStack">
>                 <interceptor-ref name="gwt"/>
>              </interceptor-stack>
>         </interceptors>
>         <default-interceptor-ref name="gwtStack"/>
>        
>     </package>
> 2. Added a struts.properties file to /WEB-INF/classes that sets the struts configuration files property:
> struts.configuration.files=pnet-struts-default.xml,struts-plugin.xml,struts.xml and then in pnet-struts-default.xml
>     I defined defaultStack to only have the GWT interceptor in it. This does not seem to help either.
> Using the configuration browser plug-in (that is a nice plug-in for this work), the interceptor stack that gets generated by Struts is this:
> Name	                                           Type
> ExceptionMappingInterceptor 	 com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor
> AliasInterceptor 	                       com.opensymphony.xwork2.interceptor.AliasInterceptor
> ServletConfigInterceptor 	        org.apache.struts2.interceptor.ServletConfigInterceptor
> PrepareInterceptor 	                    com.opensymphony.xwork2.interceptor.PrepareInterceptor
> I18nInterceptor 	                        com.opensymphony.xwork2.interceptor.I18nInterceptor
> ChainingInterceptor 	                   com.opensymphony.xwork2.interceptor.ChainingInterceptor
> DebuggingInterceptor 	                org.apache.struts2.interceptor.debugging.DebuggingInterceptor
> ProfilingActivationInterceptor 	       org.apache.struts2.interceptor.ProfilingActivationInterceptor
> ScopedModelDrivenInterceptor 	com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor
> ModelDrivenInterceptor 	                com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor
> FileUploadInterceptor 	                  org.apache.struts2.interceptor.FileUploadInterceptor
> CheckboxInterceptor 	                  org.apache.struts2.interceptor.CheckboxInterceptor
> StaticParametersInterceptor 	    com.opensymphony.xwork2.interceptor.StaticParametersInterceptor
> ParametersInterceptor 	                com.opensymphony.xwork2.interceptor.ParametersInterceptor
> StrutsConversionErrorInterceptor  org.apache.struts2.interceptor.StrutsConversionErrorInterceptor
> AnnotationValidationInterceptor     org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor
> DefaultWorkflowInterceptor 	      com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor
> My theory is that the zero-config code is either ignoring defaultStack settings and making its own stack up, or Struts is not picking up on my override of struts-default.xml (maybe I need to remove it from the JAR?). I end up getting a ClassCastException at line 150 of com.opensymphony.xwork2.validator.ValidationInterceptor, I am assuming this is the point at which Struts is trying to cast my object to a Struts result (String).

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