[cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-377 at 2/13/14 8:06 AM: ------------------------------------------------------------------- I really think we should provide a solution at spec level for CDI-377. For me the best solution is to change default bean discovery type to ‘none’ It’ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It’ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that they cannot support CDI 1.0 and 1.1 at the same time). The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it’s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn’t intend to use. was (Author: antoinesabot-durand): I really think we should provide a solution at spec level for CDI-377. For me the best solution is to change default bean discovery type to ‘none’ It’ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It’ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time). The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it’s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn’t intend to use. -- 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