[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