[cdi-dev] [JBoss JIRA] (CDI-225) Clarify whether bean discovery MAY or MUST NOT include class loading

Pete Muir (JIRA) jira-events at lists.jboss.org
Thu Aug 16 08:26:15 EDT 2012


    [ https://issues.jboss.org/browse/CDI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711978#comment-12711978 ] 

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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the cdi-dev mailing list