[cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition

[Jozef Hartinger (JIRA)]

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

Jozef Hartinger commented on CDI-456:
-------------------------------------

{quote}jozef, how should that work? The 3 beans are different but have the same beanClass(). So how should this get implemented?{quote}
Look at the example again. They do not have the same bean class. If they had the same bean class then that would be a bug.

{quote}
So what? Where in this sentence does it state that the 'bean class of the bean' cannot be null? It neither does define what the 'bean class of the bean' is used for by the container.
oh fine, but this is not about Alternatives!
Show me one single line where you read that getBeanClass() must not be null for any custom bean. 
This is just missing from the spec and we should clarify what should happen in this case.
{quote}

Very weird logic you are using here. {{BeanManager.fireEvent()}} does not specify that you cannot pass null, either. Yet, we can probably agree that calling {{BeanManager.fireEvent(null)}} is a stupid thing to do. Here, the spec clearly says that for a custom bean, CDI will call getBeanClass() to infer several pieces of information about the bean yet you feel that returning null is alright?

> fix Bean#getBeanClass() definition
> ----------------------------------
>
>                 Key: CDI-456
>                 URL: https://issues.jboss.org/browse/CDI-456
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>            Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit. 
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)