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

Pete Muir (JIRA) jira-events at lists.jboss.org
Fri Feb 22 13:05:57 EST 2013


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

Pete Muir commented on CDI-18:
------------------------------

I've updated this quite substantially to account for @Priority:

* I've removed all the stuff I moved to the interceptors spec, and updated the CDI spec to just cover any extensions it makes
* I've totally removed the xml definition of priorities, and returned XML enablement to how it worked in 1.0. This means we keep the 1.0 mechanism intact for backwards compat
* I've added global enablement using @Priority for decorators, based on the definition in the interceptors spec, and reusing priority ranges from there.
* I've added global enablement using @Priority for alternatives, based on the simple principle that the highest priority wins, as we had it before
* I've allowed @Priority to be altered during PAT
* CDI-3 allows an absolute order of interceptors, decorators and alternatives to be set in the AfterTypeDiscovery event

I know many were hoping to be able to override @Priority using xml, however I decided not to do this in the end:

(a) it keeps the XML definition clean for the 1.0 backwards compat. I tried to merge the two last time, and it ended up being tough to spec, and tough to understand, as Mark mentioned ;-)
(b) it's in keeping with the spirit of CDI to keep the XML config to an absolute minimum, especially if you can achieve the same via the portable extension SPI. As we've added that, it would be easy for an extension to implement XML ordering for any of these things, either by setting priorities, or doing a total order, or any other scheme it liked.
(c) it's less controversial, and leaves the way open for future changes if we decide they are necessary.
                
> 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
>            Assignee: Pete Muir
>            Priority: Critical
>             Fix For: 1.1.PRD
>
>
> 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


More information about the cdi-dev mailing list