[cdi-dev] Extensions and spec-related observer method injection points question

Sun Feb 19 15:07:35 EST 2017

What you can portably do is to fire an event in one CDI Extension and observe it in another Extension. Note: not a normal bean, as they are not yet started, but Extension is fine.
There is even a TCK test for it.

LieGrue,
strub

> Am 17.02.2017 um 10:36 schrieb Martin Kouba <mkouba at redhat.com>:
> 
> Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a):
>> Hi all,
>> 
>> First Laird, thanks you for all your feedback on CDI, they are very helpful.
>> This section is indeed not clear, but my understanding is this one:
>> 
>> 1) As we mention the fact that BeanManager.fire() can be invoked in an
>> extension lifecycle event observer, it makes sense to say observer on
>> lifecycle payload are supported in extension, otherwise firing an event
>> during the BeforeBeanDiscovery lifecycle event for instance would be
>> useless since the only CDI elements "discovered" at this step are
>> portable extensions
>> 
>> I tested in various Weld and OWB version, observers on non lifecycle
>> payload are called when BeanManager.fire() is called
>> 
>> 2) If extension can contain observers with custom payload that can be
>> invoked during container bootstrapping, it is quite understandable that
>> adding parameters to these observer can bring issue: matching bean may
>> not have been discovered yet and will result in an error.
> 
> That's a good point.
> 
>> So for me, it makes sense to say that having an observer injecting something else than
>> BeanManager in an extension is not safe and shouldn't be supported
>> In other words
>> 
>> void MyObserver(@Observes MyPayload payload) { ... )
>> 
>> and
>> 
>> void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... )
>> 
>> are supported in an extension, but
>> 
>> void MyObserver(@Observes MyPayload payload, MyBean bean) { ... )
>> 
>> is not because MyBean may be not discovered yet when observer will be
>> triggered.
>> 
>> Weld doesn't support it
> 
> Are you sure Antoine? I quicly checked the Weld 3 codebase and 
> "myObserver(@Observes MyPayload payload, MyBean bean)" should work. We 
> only check injection points for container lifecycle events...
> 
>> , while OWB does, so we face a non portable
>> feature here ;).
>> 
>> 3) A side effect of your mail made me also realise that we mention
>> BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we
>> should mention BeanManager.getEvent().select().fire())
>> 
>> This section really needs clarification, I'll create the ticket when we
>> agree on what is part of the spec and not ;).
>> 
>> 
>> Antoine
>> 
>> 
>> On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba <mkouba at redhat.com
>> <mailto:mkouba at redhat.com>> wrote:
>> 
>>    Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):
>>> Hi, comment inline.
>>> 
>>> ----- Original Message -----
>>>> From: "Laird Nelson" <ljnelson at gmail.com <mailto:ljnelson at gmail.com>>
>>>> To: cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>>> Sent: Thursday, February 16, 2017 11:11:41 PM
>>>> Subject: [cdi-dev] Extensions and spec-related observer method
>>    injection     points question
>>>> 
>>>> This section (
>>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>>    ) says: "If
>>>> other beans [other than the BeanManager ] are injected into an
>>    [portable]
>>>> extension’s observer methods, non-portable behavior results."
>>>> 
>>>> Rephrased: a portable extension's observer methods must have a
>>    minimum of one
>>>> parameter (the event being observed) and a maximum of two
>>    parameters (that
>>>> plus the BeanManager ), and none other if you want to stay truly
>>    portable.
>>> 
>>> That's correct interpretation.
>>> 
>>>> For true container lifecycle events, I understand this (you don't
>>    have beans
>>>> to inject yet). But given that a bean must be provided by the
>>    container for
>>>> a portable extension (
>>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events
>>    ), wouldn't
>>>> it be reasonable to permit extra injection points in a portable
>>    extension's
>>>> non -container-lifecycle-event-observing observer methods?
>>>> 
>>>> Concretely, I'd like to do this:
>>>> 
>>>> // In my portable extension
>>>> private static final void doSomethingAtStartup(@Observes
>>>> @Initialized(ApplicationScoped.class) final Object event, final
>>    Frobnicator
>>>> someBean) {
>>>> someBean.doSomething();
>>>> }
>>> 
>>> While you cannot do this, you can still get hold of BeanManager
>>    and use it to resolve your bean.
>>> 
>>>> 
>>>> ...but that would seem to be in violation of the specification.
>>    Could someone
>> 
>>    It's not a violation, it's a non-portable behavior. Weld should not
>>    complain about the injection points of the doSomethingAtStartup()
>>    observer method.
>> 
>>>> kindly explain why?
>>> 
>>> Not really sure, perhaps Martin or Antoine can share the details.
>>> But I would say this could create quite some confusion if in some
>>    observer you could inject certain beans and in others you couldn't.
>> 
>>    Yes, I think the possible confusion was the only reason.
>> 
>>> Even in your sample, you can only inject AppScoped beans, so
>>    imagine you do such observer for, say, SessionScoped, what can you
>>    inject there?
>>> SessionScoped for sure, how about Req? Conversation?
>>> 
>>>> 
>>>> Thanks,
>>>> Best,
>>>> Laird
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider
>>    licenses the code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>    ideas
>>>> provided on this list, the provider waives all patent and other
>>    intellectual
>>>> property rights inherent in such information.
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> Note that for all code provided on this list, the provider
>>    licenses the code under the Apache License, Version 2
>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>    ideas provided on this list, the provider waives all patent and
>>    other intellectual property rights inherent in such information.
>>> 
>> 
>>    --
>>    Martin Kouba
>>    Senior Software Engineer
>>    Red Hat, Czech Republic
>>    _______________________________________________
>>    cdi-dev mailing list
>>    cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>>    Note that for all code provided on this list, the provider licenses
>>    the code under the Apache License, Version 2
>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>    ideas provided on this list, the provider waives all patent and
>>    other intellectual property rights inherent in such information.
>> 
> 
> -- 
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.