[
https://issues.jboss.org/browse/CDI-312?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-312:
-----------------------------------
I'm currently thinking about removing the ProcessModule event again. This got
introduced very early in our CDI-1.1 phase before we had a common understanding about
CDI-18. Now that we have a common understanding that global enablement is a good thing we
need to review the ProcessModule event again.
Imo the pattern of programmatic per-BDA enablement doesn't fit well to the CDI 1.1
approach and I'd rather not support this. Instead I'd propose adding methods to
BeforeBeanDiscovery. e.g.
{code}
addAlternitiveDefinition(Class alternativeClass, int priority, boolean enabled);
{code}
And similar for Interceptors and Decorators.
The only probably useful feature left is getBeansXml(). But to be honest this is the same
than doing a classloader.getResources(), right?
ProcessModule doesn't reflect the @Priority changes in CDI-18
-------------------------------------------------------------
Key: CDI-312
URL:
https://issues.jboss.org/browse/CDI-312
Project: CDI Specification Issues
Issue Type: Bug
Components: Packaging and Deployment, Portable Extensions
Reporter: Mark Struberg
ProcessModule has a getAlternatives() method which returns a Set<Class> of all
enabled alternatives. This Set is mutable and can get changed via extensions. But which
'priority' should such an added Alternative have? (see CDI-18). And should this
only account for the one beans.xml or all?
Also what is about 'globally' enabled alternatives? Should they get returned in
all modules or just in the module they are enabled in?
--
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