Basically as I see it there are 3 options (aside from continuing to do what we do today, per JPA):

• utilize an enhancement added in the next CDI spec adding the ability to register a "lifecycle listener" (as in the lifecycle of the BeanManager) to the BeanManager contract. In my opinion this is the best option as it is the least complicated all around
• have the container handle this on behalf of the persistence providers (see below)
• simply delay when Hibernate makes the CDI calls from its bootstrap to the first call needing one of the CDI beans. Not a fan of this for the reasons I have already stated.

As far as WF not having "the context as to which persistence unit is targeted", I am not so sure that is true. You'd have the context of the deployment. Within that context you'd know:

1. Which PUs need CDI based on their telling you (by the calls you mention against your BeanManager wrapper)
2. The corresponding "real" BeanManager instance from the CDI provider

Granted I am not an expert at WF nor CDI but it seems like those pieces of information combined with the context you also know in terms of WF classloader and PU scopes that you could make this connection. Much easier than Hibernate itself could anyway. If you can't then you can't.

Another option I can see is for us to develop a contract between WF and Hibernate similar to what I propose CDI add. Namely, let's say that Hibernate defines a contract like:

interface BeanManagerLifecycleListener {
    void beanManagerInitialized(BeanManager realBeanManager);
    void beanManagerDestroyed(BeanManager realBeanManager);
}

interface BeanManagerExtension {
    void registerLifecycleListener(BeanManagerLifecycleListener listener);
}

And further say that the WF BeanManager wrapper that it passes to Hibernate implements that contract (in addition to BeanManager). So when Hibernate does this CDI preparation it can see whether the BeanManager reference it has also implements BeanManagerExtension and if so simply register the listener; if not it will do what it does now (or option #3 above). Later once WF knows the "real BeanManager" it can call the into the listener and Hibernate will do its thing.

Something else to keep in mind is that this will only become more common of an issue as JPA 2.2 makes AttributeConverters CDI capable as well. AttributeConverters are far more widely used then listeners.