In a Portable Extension, how do I obtain an instance of the bean required to be created for it?

[ljnelson]

I am in a portable extension.  I am aware that when my extension is instantiated, it is via the ordinary old ServiceLoader mechanism; consequently, my default constructor is called and obviously no dependency injection takes place since ServiceLoader is invoking new.

Now, the specification reads in part:

For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier @Default, supporting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces.

Suppose in my extension's "normal" instance, the one created by the ServiceLoader machinery, and which is invoked during container lifecycle event observance, at a point suitably late in the container lifecycle (like during AfterDeploymentValidation), I wished to get the contextual reference for this bean via the BeanManager.  Should dependency injection be performed on it (this is why I was hoping this would work)?  I placed @Inject on a different constructor in my extension, and it is never called.  Nevertheless I got a reference back from the bean manager.

My larger use case is that I am looking for a way to leverage a configuration framework-like series of producers that can read properties files etc. to configure my portable extension.  I am lucky that I don't need to perform this work until AfterDeploymentValidation-time, so I was hoping there was an easy hack here.

Best,

Laird

[ljnelson]

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

[manovotn]

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.

[ljnelson]

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!