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

Antoine Sabot-Durand antoine at sabot-durand.net
Fri Feb 17 04:19:46 EST 2017


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. 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, 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> wrote:

> Dne 17.2.2017 v 07:08 Matej Novotny napsal(a):
> > Hi, comment inline.
> >
> > ----- Original Message -----
> >> From: "Laird Nelson" <ljnelson at gmail.com>
> >> To: 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
> >> 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
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/4dd1d035/attachment.html 


More information about the cdi-dev mailing list