[cdi-dev] [JBoss JIRA] (CDI-245) Promote the right way how extensions should communicate with each other during container initialization

[Pete Muir (JIRA)]

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

Pete Muir commented on CDI-245:
-------------------------------

I pondered for a while over that same paragraph, when I came to my conclusion that extensions aren't defined as beans. Typically, when the spec wants something to be a bean, it says "is a ... bean" e.g. 3.1.1 (Managed beans)

{quote}
A top-level Java class is a managed bean if it is defined to be a managed bean
{quote}

or 3.2 (Session beans)

{quote}
A session bean is a bean that is implemented by a session bean with an EJB 3.x client view. 
{quote}

On the other hand, when the spec wants the container to provide a bean which provides access to an externally managed resource it says "must provide a bean" e.g. 3.7 (Additional built-in beans)

{quote}
A Java EE or embeddable EJB container must provide the following built-in beans, all of which have qualifier @Default:

a bean with bean type javax.transaction.UserTransaction, allowing injection of a reference to the JTA UserTransaction,

(etc)
{quote}

To me, it's fairly clear that the spec isn't saying "UserTransaction is bean", but is saying "There must be a bean that represents the UserTransactions".

Here, the spec clearly uses the second form, so my reading is that "the container must provide a bean that represents the extension".

I think this reading is backed by the spec saying "An extension is a service provider..." and "For each service provider,...", and then going on to refer to the "extension", and not the "extension bean". Firstly, because it clearly says "an extension *is a* service provider" and not "an extension is a bean implemented by a service provider" (or better written words to that effect). Secondly, because the spec is quite clear about when something is a bean or not elsewhere, and here it makes no effort to say "an extension is a service provider".

WDYT? Do you see why I came to this conclusion?

Regarding field injection into a service provider, I don't believe that has ever been allowed specifically by the specification (it always talked about injection into the observer method only), and I think that this makes sense. The "If other beans are injected into a service provider" was something I added to EDR1, that I think was a mistake now.

I also choose not to address defining anything other than the container firing lifecycle events as non-portable, as I don't believe I have a good answer to that question right now. I would actually much prefer we restrict it by defining something on observer methods such as "an extension observer method need only to respond to container lifecycle events fired by the container and need not respond to events fired by an application" or something like that. WDYT?
                
> Promote the right way how extensions should communicate with each other during container initialization
> -------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-245
>                 URL: https://issues.jboss.org/browse/CDI-245
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.0, 1.1.EDR
>            Reporter: Martin Kouba
>            Assignee: Pete Muir
>             Fix For: 1.1.PRD
>
>
> This is not clear right now. The spec allows (does not forbid) extensions to fire regular events via {{BeanManager}} and I believe this should be _the right way_. See also CDI-109 discussion. However we should also state that extensions _may not fire container lifecycle events_ as this could lead to unexpected results (and it's pretty broken imho).

--
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