[
https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys...
]
Ales Justin commented on CDI-18:
--------------------------------
> Folks, introducing any hierarchy is exactly the same way broken
as BDA itself. Let's just get rid of that piep!
I would say having that *piep* is not so *piep* at all, as it allows you to abstract away
diff CL rules.
Who's to say which CL rules are right. ;-)
e.g. JBossAS pre-7 was doing well with that big-ball-o-mud, until that bbom become
unmanageable (via JEE expansion ...).
And even if we went directly to modularity / CL, you still need a mechanism to
"visit" things API way.
Since CL doesn't expose that, you need a custom layer -- here enter BDA. ;-)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira