[
https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys...
]
Dmitri Zamysloff commented on CDI-18:
-------------------------------------
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