Steve Ebersole I'd like to hear what the CDI enhancements might be in the future for "application deployment level" listeners. Whether that is the new listener approach that you suggested or a javax.enterprise.inject.spi.Extension enhancement. Regardless, this really is sounding like the 3rd PU bootstrap phase, since the deferred calls to the BeanManager may throw exceptions, that likely should lead to the EntityManagerFactory being closed.

I'm not yet sure about WildFly "queuing up" the bean manager calls until the right time, which doesn't make this problem any easier. It just pushes the work onto WildFly, with a complicated api that supports queuing the following calls:

			this.creationalContext = beanManager.createCreationalContext( null );
			this.instance = injectionTarget.produce( creationalContext );
			injectionTarget.inject( this.instance, creationalContext );
			injectionTarget.postConstruct( this.instance );

When CDI calls the WildFly AfterDeploymentValidation extension, we still have no context as to which persistence unit is targeted. I suppose that WildFly could cast the parameters passed to the callback (org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl which offers us nothing public that we need at the moment). I suppose the WF AfterDeploymentValidationImpl might be extended to offer a solution at the weld-core-impl.jar implementation level.

If CDI can make it possible for Hibernate to get the right notification + context, I think that is the best approach (since the AfterDeploymentValidation interface allows us to report deployment exceptions, which IMO is more useful than ignoring CDI registration errors).

If we do nothing else and implement your idea for "delaying CDI registration", would that be configurable via a persistence unit property? If delaying CDI registration, requires getting a synchronization lock, it might be good to have the option of registering with CDI early.