[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=12718259#comment-12718259 ] 

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

Sorry, producers of course not providers :)

And yes I red it all above. I mean it is still not clear for me if it would be possible specify interceptors for example in WEB-INF for whole classes graph in web application or not?

Right now as described in my post which I have linked we have an issue in jboss. It is pity that we have to register interceptors in each jar where we use them. What I really want to avoid is that the teams which work on parts of our huge solution must be aware of which interceptor classes they have to register in their jar's beans.xml files. I want that they just put empty beans.xml in their jar just to mark one for CDI scanner. I mean probably idea of scopes with levels jar->app->enterprise is not the bad one? 

Regarding desktop we trying already to adopt weld for our fat client. Everybody here is just infected with CDI. It simplifies a lot of stuff but we need clear playing rules. Rules which help you but not make it inflexible.
                
      was (Author: dzcs):
    Sorry, producers of course not providers :)

And yes I red it all above. I mean it is still not clear for me if it would be possible specify interceptors for example in WEB-INF for whole classes graph in web application?

Right now as described in my post which I have linked we have an issue in jboss. It is pity that we have to register interceptors in each jar where we use them. What I really want to avoid is that the teams which work on parts of our huge solution must be aware of which interceptor classes they have to register in their jar's beans.xml files. I want that they just put empty beans.xml in their jar just to mark one for CDI scanner. I mean probably idea of scopes with levels jar->app->enterprise is not the bad one? 

Regarding desktop we trying already to adopt weld for our fat client. Everybody here is just infected with CDI. It simplifies a lot of stuff but we need clear playing rules. Rules which help you but not make it inflexible.
                  
> 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