[cdi-dev] Extensions and spec-related observer method injection points question
Antoine Sabot-Durand
antoine at sabot-durand.net
Fri Feb 17 04:52:59 EST 2017
On Fri, Feb 17, 2017 at 10:36 AM Martin Kouba <mkouba at redhat.com> wrote:
> 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...
>
Oops, you're right, I was a bit too fast in my writing, what is not
supported in Weld (tested with 2.3.2, 2.4.2 and 3.0.0-CR1)and works in OWB
is
void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object
payload, MyBean bean) { ... )
Weld throws the following exception:
WELD-000409: Observer method for container lifecycle event can only inject
BeanManager
Which is not very clear since the payload is not exactly a container
lifecycle event...
> >, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/0a43985d/attachment.html
More information about the cdi-dev
mailing list