[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] Colin Decker commented on CDI-377: ---------------------------------- I think this issue should be reopened. CDI 1.1's handling of JSR-330 annotations in jar files on the classpath is overly eager and causes problems for libraries that simply want to include JSR-330 annotations to make it easy to use those classes with JSR-330 compatible frameworks. I feel that CDI 1.1 is effectively violating JSR-330 by assuming the presence of its standard annotations (for example, @Singleton) means not that a class *can* be injected but that it *must* be injected. This has caused problems for users of Guava, as indicated in the linked Guava issue. We tried to help those users by adding a beans.xml to the Guava jar with bean-discovery-mode=none, but that breaks CDI 1.0 users because the presence of beans.xml in the jar causes CDI 1.0 to scan the jar where it didn't before, while the bean-discovery-mode, being new in CDI 1.1, is ignored. This is a frustrating situation as it seems to mean that Guava has to choose between working out of the box for CDI 1.0, working out of the box for CDI 1.1, or removing the JSR-330 annotations entirely, an inconvenience to users of other JSR-330 frameworks. In short, CDI should respect the fact that JSR-330 annotations are a shared standard and should not handle them in ways that restrict their use in libraries. They should never, on their own, be treated a signal that a class must be instantiated and injected. At a minimum, requiring a beans.xml file in the jar as an explicit acknowledgement that the jar wants be handled according to CDI's specification, as CDI 1.0 does, seems reasonable. -- 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