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