[JBoss JIRA] (CDI-225) Clarify whether bean discovery MAY or MUST NOT include class loading
by Harald Wellmann (JIRA)
Harald Wellmann created CDI-225:
-----------------------------------
Summary: 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira