[cdi-dev] [JBoss JIRA] (CDI-227) BeanManager#resolve() is underspecified for corner cases

[Mark Struberg (JIRA)]

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

Mark Struberg commented on CDI-227:
-----------------------------------

Martin, please read "5.1 Modularity"

In CDI-1.0 an @Alternative has to be enabled for a certain jar. If strictly interpreted was *not* available in another jar. That's of course not user friendly, so this was not implemented by many containers that way. Early Weld containers had it that strictly but even Weld doesn't follow this spec rule anymore. But it is certainly defined that way in CDI-1.0.

But even for CDI-1.1 where we have global enablement (see CDI-18) this bullet is not useless imo.

Imagine you have an EAR with 2 WebApps. An @Alternative x2 for interface X (default implementation x1)is defined in webappA but not in webappB. Thus the phrase 'is available for injection in the module'.

Or do you think this is covered elsewhere already?

                
> BeanManager#resolve() is underspecified for corner cases
> --------------------------------------------------------
>
>                 Key: CDI-227
>                 URL: https://issues.jboss.org/browse/CDI-227
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java SE Integration, Packaging and Deployment
>    Affects Versions: 1.0, 1.1.EDR
>            Reporter: Guy Veraghtert
>            Assignee: Pete Muir
>              Labels: patch
>             Fix For: 1.1.PRD
>
>
> The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's.
> For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception.
> To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory  developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples).
> Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ...
> Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice.
> These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira