Uploaded image for project: 'CDI Specification Issues'
  1. CDI Specification Issues
  2. CDI-225

Clarify whether bean discovery MAY or MUST NOT include class loading



    • Clarification
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Rejected
    • 1.1.EDR
    • None
    • Resolution


      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

      public class OptionalBean

      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.




            pmuiratbleepbleep Pete Muir
            hwellmann.de Harald Wellmann (Inactive)
            0 Vote for this issue
            4 Start watching this issue