[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-699) Allow packages to define their own default interceptors

[Chris Rudd (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBSEAM-699?page=comments#action_12362184 ] 
            
Chris Rudd commented on JBSEAM-699:
-----------------------------------

The current initDefaultInterceptors attempts to do some "smart" processing only adding interceptors that are needed (based on the classes layout / metadata).

What if the @Interceptor that can be applied to class level annotations was also appied to method and field level annotations.

I.e. Currently ant class level annotation that itself is annotated with @Interceptor ( <interceptor> ) will instruct the component to install the interceptor <interceptor>.

If the same is applied to fields/methods than the @Restirct could be modified to be :

@Target({TYPE,METHOD})
@Documented
@Retention(RUNTIME)
@Inherited
@Interceptor(SecurityInterceptor.class)
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 "";
}

Then applied like so :

@Name("foo")
public class Foo
{
   @Restrict
   public void doIt() { }
}

@Name("bar")
public class Bar
{
    public void doIt() { }
}


Under this new scenario the component infrastructure would isntall the SecurityInterceptor for component foo but not for bar.


> Allow packages to define their own default interceptors
> -------------------------------------------------------
>
>                 Key: JBSEAM-699
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-699
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.3.0.BETA1
>
>
> Currently, all default interceptors get listed out in an ugly method on Component. This is extremely non-extensible. We need some way to externalize that code to the package that needs the interceptor. This would let us split out security to its own jar, for example.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira