Re: [wildfly-dev] duel between JPA use of ClassFileTransformer and CDI implicit/explicit Bean Manager (why can't we just get along)...

More inline below. Here is part of JPA 2.1 section 3.5.1 Entity Listeners: " Entity listener classes in Java EE environments support dependency injection through the Contexts and Dependency Injection API (CDI) when the containing archive is a bean archive. An entity listener class that makes use of CDI injection may also define lifecycle callback methods annotated with the PostConstruct and PreDestroy annotations. These methods will be invoked after injection has taken place and before the entity listener instance is destroyed respectively. The persistence provider is responsible for using the CDI SPI to create instances of the entity listener class; to perform injection upon such instances; to invoke their PostConstruct and PreDestroy methods, if any; and to dispose of the entity listener instances. An entity listener is a noncontextual object. In supporting injection into entity listeners, the persistence provider must behave as if it carries out the following steps involving the use of the CDI SPI. * Obtain a BeanManager instance. * Create an AnnotatedType instance for the entity listener class. * Create an InjectionTarget instance for the annotated type. * Create a CreationalContext. * Instantiate the listener by calling the InjectionTarget produce method. * Inject the listener instance by calling the InjectionTarget inject method on the instance. * Invoke the PostConstruct callback, if any, by calling the InjectionTarget postConstruct method on the instance. When the listener instance is to be destroyed, the persistence provider must behave as if it carries out the following steps. * Call the InjectionTarget preDestroy method on the instance. * Call the InjectionTarget dispose method on the instance. * Call the CreationalContext release method. Persistence providers may optimize the steps above, e.g. by avoiding calls to the actual CDI SPI and relying on container-specific interfaces instead, as long as the outcome is the same. Entity listeners that do not make use of CDI injection are stateless. The lifecycle of such entity listeners is unspecified. When invoked from within a Java EE environment, the callback listeners for an entity share the enterprise naming context of the invoking component, and the entity callback methods are invoked in the transaction and security contexts of the calling component at the time at which the callback method is invoked. " On 06/08/2013 12:59 PM, Jason Greene wrote: If Hibernate waited until the application persists/loads an entity to create the CDI injection targets, would that be too late for CDI to do its magic? The entity listeners fire pre/post events on { persist, remove, update, load}. If a CDI bean manager is available, PostConstruct and PreDestroy events are fired on the entity listener class. https://gist.github.com/scottmarlow/5743641 shows a deployment time call stack for hibernate invoking org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget for an entity listener class. I think that we should also adopt a (JPA) two phased approach to bootstrapping the persistence unit (use of datasources + bean manager, would only be allowed in the second phase). We might partially, solve this by using Hibernate extensions (in JipiJapa for using the two phase bootstrap). However, I'm hoping for something better to come out of the discussion on the JPA 2.1 EG discussion just raised.