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

Ameya commented on WW-2560:
---------------------------

Thanks. Here are the details with a bit of summary.

Actually our struts.xml consists of actions which have action mappings that 
contain the param tags in the action (as shown below). The param tag (e.g. 
"role" defined above) is used by our custom interceptors. E.G. Definition is 
given below: 

     <package name="def" extends="struts-default">
                        ......
                        <interceptor-stack name="authStack">
                                <interceptor-ref name="chain"/>
                                <interceptor-ref 
name="DefaultStack"></interceptor-ref>
                                <interceptor-ref name="annotationWorkflow"/>
                        </interceptor-stack>
                        .......

                      <action name="updatePk"
                                    class="com.mypk.pk1Action"
                                    method="update">
                                 <result type="tiles">pk1.detail</result>
                                 <result name="input" 
type="tiles">pk1.cancel</result>

                                 <param 
name="role">ROLE_XXX;ROLE_XXX;ROLE_XXX</param>

                     </action> 
                       
                    .........
      </package>

Hence in our existing approach (with the Struts action mappings) the role 
Attribute is populated in the pk1Action first (because of the 
StaticParamsInterceptor) and then our custom interceptors (which are annotated 
by @before) use this "role" attribute . The getter/setter for this role 
attribute is defined in our BaseAction class. 

Now - moving forward we would like to move to a zero configuration approach and 
eliminate the Struts XML mappings for new actions. So, how do we populate this 
parameter i.e. (role attribute) using annotations? I could not find a way 
through annotation. 

So as a workaround we do,

@Results({
    @Result(name=Action.SUCCESS,         
            value="pk1.detail",              
            type=TilesResult.class),
    @Result(name=Action.INPUT,           
            value="pk1.cancel",                  
            type=TilesResult.class)),
})
@ParentPackage(value="def")
public class pk1Action extends BaseAction
{
       ..........
        public void prepare()
        {
               log.info("in prepare ");
               setRole("ROLE_ADMIN");
        }

        .........
}

Is there a way to directly populate these using annotation instead of using the 
prepare? Or can this be provided when @Action annotation is introduced?

> Annotation support for setting parameters (defined in <action> tag) from 
> struts.xml to associated action property
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WW-2560
>                 URL: https://issues.apache.org/struts/browse/WW-2560
>             Project: Struts 2
>          Issue Type: New Feature
>          Components: Plugin - CodeBehind
>    Affects Versions: 2.0.11.1
>         Environment: Windows XP
>            Reporter: Ameya
>
> As per the issues reported (WW-1866, WW-1796 and WW-2016), Action annotation 
> should also support populating the action properties from parameters defined 
> in struts.xml. 
> E.G. Action below. 
>       <action name="updatePk"
>               class="com.mypk.pk1Action"
>               method="update">
>               <result type="tiles">XXX.detail</result>
>               <result name="cancel" type="tiles">XXX.cancel</result>          
>               <param name="role">ROLE_XXX;ROLE_XXX;ROLE_XXX</param>
>       </action>
> The Action annotation should have support for the param tag also. The role 
> String (in above case) should be pk1Action.  The pk1Action has the associated 
> getRole( ) and setRole(String) method. 

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

Reply via email to