I wanted to clarify my suggestion because it confused Scott at least. Basically my suggestion is completely separate from Martin's. In my opinion, Martin's suggestion will not work because of the lack of context (association between BeanManager and PU). So my suggestion does not rely on Martin's at all. It does not suggest using AfterDeploymentValidation, because again I do not believe that will work, at least not portably.

Also keep in mind that, bottom line, JPA mandates how we as a JPA provider are expected to receive access to the BeanManager. It is very clear. As as a JPA provider we need to comply with that expectation.

Another point came out of the discussion Scott and I had on IRC. So there is a chicken/egg dependency problem here. JPA needs CDI; CDI needs JPA. In the absence of limitations/assumptions this is never going to be resolvably reliably. The weight all seems to be to force the JPA provider to handle this. Which is fine. However in my opinion there needs to be a limitation here. Namely I think it needs to be a requirement that no CDI bean attempt to actually use the PU during deployment. The whole premise to fix this is that Hibernate should delay its CDI calls. Which is fine, but that implies that Hibernate will not be usable until after the point that it is able to make those CDI calls.

So my suggestion is to develop a CDI extension in the form of the BeanManagerExtension/BeanManagerLifecycleListener contracts. Obviously this will not make it into the CDI spec anytime soon, so for the short term I suggest that we develop it as a custom extension between Hibernate and WildFly. The following description follows our already proprietary 2-phase bootstrapping. So as part of the first phase, WildFly will pass in the BeanManager reference as per JPA guidelines. What WildFly actually passes (even today) is its own BeanManagerForwarder lazy wrapper implementation. So the first part of the suggested change is that WildFly's BeanManagerForwarder will additionally implement the BeanManagerExtension interface. Hibernate, during its bootstrap, will see the BeanManager and see that it implements BeanManagerExtension and rather than immediately making the CDI calls will instead register a BeanManagerLifecycleListener. Again, that routes to WildFly's BeanManagerForwarder which will store a reference to the BeanManagerLifecycleListener reference Hibernate passed it. Later as part of the 2nd bootstrap phase, WildFly will :

1. build the EMF, making it available (again still not usable)
2. this allows WildFly to build the CDI BeanManager
3. at this point WildFly would call into the BeanManagerLifecycleListener reference it got (and stored) from Hibernate passing the "real" BeanManager.