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
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.