[jboss-jira] [JBoss JIRA] (WFLY-1145) missing beans.xml in archive using javax.inject shouldn't *silently* ignore injection sites

missing beans.xml in archive using javax.inject shouldn't *silently* ignore injection sites ------------------------------------------------------------------------------------------- Key: WFLY-1145 URL: https://issues.jboss.org/browse/WFLY-1145 Project: WildFly Issue Type: Feature Request Security Level: Public(Everyone can see) Components: CDI / Weld Environment: N/A, any Java EE 6 Reporter: Craig Ringer Priority: Minor Labels: cdi, injection, injectionpoint, usability It's common, especially for new users of Java EE and CDI, for confusion to arise because of a missing or misplaced beans.xml file. Injection sites that should be injected are null, interceptors don't run, etc. People experienced with CDI immediately spot what's wrong, but if you haven't worked with EE much it can throw you quite badly. It's particularly problematic when beans.xml exists, but isn't where the server expects it to be. This can happen when a jar-layout archive is deployed as a .war or vice versa (something newbies can and will do), or when beans.xml is placed in META-INF/ for a war archive where it's supposed to be in WEB-INF/ . It would be very helpful if it were possible to efficiently detect an archive that uses javax.inject.* annotations without a beans.xml file and issue a warning. To enhance the usability of CDI and its accessibility to new developers, IMO the spec should encourage this. A deployment error when javax.inject.Inject etc are used without a beans.xml file isn't appropriate, as there may be non-CDI code using those annotations, but a warning would make a big difference to usability. It's possible this is better done in an application-server specific context rather than as anything to do with the CDI specification, since the AS is scanning the archive during deployment anyway. If that's the case, it's probably best to move this issue to the JBoss AS 7 JIRA. If it's possible for a CDI impl to *efficiently* detect javax.inject.* and warn, though, it'd be a good thing to encourage in the spec.