[cdi-dev] [JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

[Dmitri Zamysloff (JIRA)]

    [ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718203#comment-12718203 ] 

Dmitri Zamysloff edited comment on CDI-18 at 9/13/12 7:34 AM:
--------------------------------------------------------------

Hi together, 

as the follow-up to the thread https://community.jboss.org/thread/200853.

INTERCEPTORS

The specification says that the "beans.xml" is valid per beans archive. But as a specification user I would prefer to have the validity of registered interceptors hierarchically. That means following:

IN CONTAINER

1. The first level where the beans.xml file must appear is the bean archive (jar file) if and only if the classes in jar utilize CDI. Already there the first interceptors can be defined. In other words 
   - I CAN say which interceptors I want to use per default for my interception bindings. Defined interceptors will be active only if this definition is not overridden on upper level. AND
   - if within the jar I declare interceptors I MUST create META-INF/beans.xml where I CAN register my interceptors. My registered interceptors will be active for all binding and not only in this particular jar only in case my jar is together with other jars in class path and my interceptors are not overridden in upper layers or in jar which use interceptor bindings itself.
  
2. The second and third level are the web/service/resource and enterprise applications respectively. On these levels the application assembly must be able to override the interceptors defined on lower level. Means: if I have registered interceptor for @Foo @Default in jar, the application which have this jar in class path can override registered interceptor by registering another interceptor for the same binding and qualifier in own beans.xml file.

DESKTOP
1. The first level as in container.
3. The desktop applications which utilize CDI instantiating implementation directly must be able to provide top-level beans.xml to the implementation. Ddefinitions in this beans.xml will override existing interceptor registrations on class path.

------------------------

PROVIDERS

I think it is necessary to clarify the situation with providers also. what happens so far if I have two providers of the same type in class path????
                
      was (Author: dzcs):
    Hi together, 

as the follow-up to the thread https://community.jboss.org/thread/200853.

INTERCEPTORS

The specification says that the "beans.xml" is valid per beans archive. But as a specification user I would prefer to have the validity of registered interceptors hierarchically. That means following:

IN CONTAINER

1. The first level where the beans.xml file must appear is the bean archive (jar file) if and only if the classes in jar utilize CDI. Already there the first interceptors can be defined. In other words 
   - I CAN say which interceptors I want to use per default for my interception bindings. Defined interceptors will be active only if this definition is not overridden on upper level. AND
   - if within the jar I declare interceptors I MUST create META-INF/beans.xml where I CAN register my interceptors. My registered interceptors will be active for all binding and not only in this particular jar only in case my jar is together with other jars in class path and my interceptors are not overridden in upper layers or in jar which use interceptor bindings itself.
  
2. The second and third level are the web and enterprise applications respectively. On these levels the application assembly must be able to override the interceptors defined on lower level. Means: if I have registered interceptor for @Foo @Default in jar, the application which have this jar in class path can override registered interceptor by registering another interceptor for the same binding and qualifier in own beans.xml file.

DESKTOP
1. The first level as in container.
3. The desktop applications which utilize CDI instantiating implementation directly must be able to provide top-level beans.xml to the implementation. Ddefinitions in this beans.xml will override existing interceptor registrations on class path.

------------------------

PROVIDERS

I think it is necessary to clarify the situation with providers also. what happens so far if I have two providers of the same type in class path????
                  
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
>                 Key: CDI-18
>                 URL: https://issues.jboss.org/browse/CDI-18
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans, Decorators, Interceptors, Packaging and Deployment
>    Affects Versions: 1.0
>            Reporter: Mark Struberg
>            Priority: Critical
>             Fix For: 1.1 (Proposed)
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml). 
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira