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

[Mark Struberg (JIRA)]

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

Mark Struberg commented on CDI-225:
-----------------------------------

Hi Harald!

@Requires(class) is not portable. I already reported this to the Seam team. That's also the reason why we agreed to NOT support this use case in the DeltaSpike @Exclude annotation.

We discussed this stuff as part of the @Veto discussion. See CDI-50 and CDI-216.
I assume this one is a duplicate of CDI-50, wdyt?
                
> 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