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