]
Pete Muir commented on CDI-225:
-------------------------------
The intent was to leave this unspecified, as typically this is an implementation choice.
What we can do is provide rules about what can/can't happen during bean discovery.
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
Fix For: 1.1 (Proposed)
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: