[cdi-dev] [JBoss JIRA] (CDI-225) Clarify whether bean discovery MAY or MUST NOT include class loading

Clarify whether bean discovery MAY or MUST NOT include class loading -------------------------------------------------------------------- Key: CDI-225 URL: https://issues.jboss.org/browse/CDI-225 Project: CDI Specification Issues Issue Type: Clarification Components: Resolution Affects Versions: 1.1.EDR1 Reporter: Harald Wellmann The CDI 1.0 spec and also the current 1.1 draft is rather vague about the issue of class loading vs. class file byte code scanning for bean discovery. By default, I would assume the term "class" in a specification to refer to a loaded class, unless explicitly stated otherwise. A feature like Seam Solder's {code} @Requires(OptionalDependency.class) public class OptionalBean {code} will necessarily break if the CDI container loads OptionalBean during bean discovery - when OptionalDepencency is not available, OptionalBean cannot be loaded, and the CDI container won't even see the @Requires annotation. See also http://seamframework.org/Seam3/Compatibility, Section Overzealous class scanner. The way I read the CDI spec, GlassFish is fully spec compliant (but maybe not very efficient) in loading bean archive classes for the purpose of discovery. @Requires is also spec compliant, but not portable because it tacitly assumes that classes get scanned but not loaded. So if scanning in place of loading has been a tacit assumption of the CDI 1.0 authors all the time, it should be made explicit in CDI 1.1. Otherwise, if loading is also a valid option, this should be clearly stated so that extension authors will not rely on accidental features of a given CDI implementation.