I can see on further reading that the bean that must be provided by the container needs merely to support injection of a reference to the extant service provider instance.  That means that indeed no injection would take place.

It looks like I can very nastily use Unmanaged here if I really want to go that way.  :-)

Thanks,

Best,

Laird

Matej Novotny wrote:

 

Hi Laird,

 

if I understand your question correctly, you basically want to @Inject into an extension. That you cannot do, apart from injection of BeanManager. The reason why injection into extensions cannot work is that they are processed before you actually start booting CDI container (in order to be able to react upon that boot). Now BM itself will allow you to do majority of things you might aim to do, however its functions will only work if invoked after a certain container lifecycle event. For instance, you obviously cannot use BM to resolve a bean in ProcessAnnotatedType phase. However as you said you can make use of AfterDeploymentValidation and I think vast majority of BM's functionality will work there.

You are correct.  And I understood that dependency injection doesn't occur on initial creation of the extension.  I was hoping that at the time the container made a contextual reference available it would clone it or otherwise call the equivalent of UnmanagedInstance#inject() on it, but I see that it does not.  So I am just creating a new unmanaged instance of "myself" instead, and performing the injection there to take advantage of my configuration framework.  Thanks!