Martin Kouba
See Steve's responses above. Mine are at the bottom of this comment.

Another related question, is how the "application deployment level" BeanManager that is passed to the persistence provider (via map parameter "javax.persistence.bean.manager" of PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map)), corresponds to the BeanManager(s) passed to the AfterDeploymentValidation callback.

Whether the Hibernate listener is registered via the "application deployment level" BeanManager (via CDI future enhancements) or via the current CDI AfterDeploymentValidation callback (which as we find here, also needs enhancements), we need a way to ensure that the right BeanManager is accessible to the Hibernate event listener.

...any suggestions on how the javax.enterprise.inject.spi.AfterDeploymentValidation event parameter can be used...

Sorry I have no idea. A static method accessing the "current" Hibernate config?

There is no "current" Hibernate configuration as the app server may be using multiple threads for application deployment, as WildFly does.

...If a getDeploymentBeanManager method were added to the AfterDeploymentValidation interface,...

This is not possible. AfterDeploymentValidation comes from the CDI API which does not define anything like "deployment" BeanManager or BeanManager hierarchy (it's impl specific).

It would be nice if we could enhance the CDI API, to allow a "application deployment level" BeanManager to have an EventListener associated with it that runs at AfterDeploymentValidation time. At least, there should be a way for Hibernate to register a key/value pair with the "application deployment level" BeanManager that is (API) available to the AfterDeploymentValidation event callback.

Make sense? IMO, it would also be nice if we could nail this down in time for the JPA 2.2 discussion, so that all (2.2) persistence providers could leverage this.