On Fri, Feb 17, 2017 at 9:30 AM Antoine Sabot-Durand <antoine@sabot-durand.net> wrote:

Regarding Extension being beans, it's the case, but rather special beans since you can't perform field, constructor or initializer injection in them.

Sure; obviously there are issues with exactly when a portable extension "becomes" a bean. You don't want to use "bean-like" features while the container is still coming up.

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.

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.

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: https://blog-rmannibucau.rhcloud.com/#/post/share-data-in-cdi-extensions)
Create a specific bean to declare your observers and inject the extension and other beans as parameter.

Yes; I am heading this way. I had some shared state across lifecycle event observers and "regular" observers and was hoping to keep that isolated to a private instance variable but I can refactor this.

If you really want to have your observers in your extension, inject BeanManager and perform the resolution with it...

That's what I'm doing now but it doesn't "read" as nicely; that's fine.

Best,

Laird