[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1544) Extend @Restrict annotation to allow specifying the "action" and "args" parameters for the s:hasPermission call.

Extend @Restrict annotation to allow specifying the "action" and "args" parameters for the s:hasPermission call. ---------------------------------------------------------------------------------------------------------------- Key: JBSEAM-1544 URL: http://jira.jboss.com/jira/browse/JBSEAM-1544 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 1.3.0.ALPHA Reporter: Chris Rudd Assigned To: Gavin King Fix For: 1.3.0.BETA1 I'm currently using a decendant of the Home objects that uses the specifis @Restrict on the update/persist and remove methods. The different Home objects are defined via configuration. This all works great, except that there isnt a way to get at the particular instance that the Home object is operating on, or alter the action that will be checked. I propose making the following changes to @Restrict and the SecurityInterceptor : @Target({TYPE,METHOD}) @Documented @Retention(RUNTIME) @Inherited public @interface Restrict { /** * Restrictions may be expressed using any EL expression, and usually * include the use of s:hasRole(...) or s:hasPermission(..., /..). * * @return An EL expression that defines the restriction to be checked */ String value() default ""; /** * If specified the value will be used for the action instead of the method name. */ String action() default ""; /** * If specified the values will be passed as the args parameter of the s:hasPermission check. */ String[] args() default {}; } Then the createDefaulExpr can use the Restrict to override the method name and args such that @Restrict( action="delete", args = "component.instance" ) would generate #{s:hasPermission( <component name>, 'delete', component.instance )}, provided that the current component is exposed as "component" . The would allow the auto use of the component name (needed for use when defining components via configuration), yet still provide the ability to "tweak" the default Restrict check. The component would need to be exposed as "component" since the final component name is unknown until configuration time. Alternatly you could do some thing like #component.instance, and do a string replace of #component with the effective component name as part of the formatting of the defaultExpr.