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