<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 17, 2017 at 9:30 AM Antoine Sabot-Durand &lt;<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>&gt; 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_msg">Regarding Extension being beans, it&#39;s the case, but rather special beans since you can&#39;t perform field, constructor or initializer injection in them.</div></div></blockquote><div><br></div><div>Sure; obviously there are issues with exactly when a portable extension &quot;becomes&quot; a bean.  You don&#39;t want to use &quot;bean-like&quot; features while the container is still coming up.</div><div> </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_msg">For observer that might be called during bootstrap (observing Object for instance) they will throw exception if they inject parameters as well since their matching beans are not resolvable yet.</div></div></blockquote><div><br></div><div>Right; this was an excellent point you made earlier—specifically the part about observing Object; the related point that other observer method parameters might not be resolved seemed irrelevant to me, since by definition a non-container-lifecycle-event-observing observer method would not be invoked until deployment validation was complete—and which I had not thought about.</div><div> </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_msg">A good practice could be: use observers with personal payload without parameter injection and only for specific operation during bootstrap (Romain wrote an interesting post on the topic: <a href="https://blog-rmannibucau.rhcloud.com/#/post/share-data-in-cdi-extensions" class="gmail_msg" target="_blank">https://blog-rmannibucau.rhcloud.com/#/post/share-data-in-cdi-extensions</a>)</div><div class="gmail_msg">Create a specific bean to declare your observers and inject the extension and other beans as parameter.</div></div></blockquote><div><br></div><div>Yes; I am heading this way.  I had some shared state across lifecycle event observers and &quot;regular&quot; observers and was hoping to keep that isolated to a private instance variable but I can refactor this.</div><div> </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_msg">If you really want to have your observers in your extension, inject BeanManager and perform the resolution with it...<br></div></div></blockquote><div> </div><div>That&#39;s what I&#39;m doing now but it doesn&#39;t &quot;read&quot; as nicely; that&#39;s fine.</div><div><br></div><div>Best,</div><div>Laird</div></div></div>