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

Martin Kouba mkouba at redhat.com
Fri Feb 17 04:36:21 EST 2017


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


More information about the cdi-dev mailing list