The following are the spec changes I propose to capture the semantics
of support for CDI injection into entity listeners.
Please let me know as soon as possible if you have any corrections,
disagree with any of this, etc., etc.
thanks,
-Linda
------
The following is intended for insertion into section 3.5 (Entity
Listeners and Callback Methods):
Entity listener classes in Java EE environments support dependency
injection through CDI when the containing archive is a bean archive.
An entity listener class that makes use of CDI injection may also
define PostConstruct and PreDestroy methods. 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.
The persistence provider is only required to support CDI injection
into entity listeners in Java EE container environments. If the
containing archive is not a bean archive, the BeanManager will not be
available, and the persistence provider must not invoke entity
listeners that depend upon CDI injection.
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.
(See [CDI spec] and [Weld reference]).
1. Obtain a BeanManager instance. (See section 9.1.)
2. Create an AnnotatedType instance for the entity listener class.
3. Create an InjectionTarget instance for the annotated type.
4. Create a CreationalContext.
5. Instantiate the listener by calling the InjectionTarget produce method.
6. Inject the listener instance by calling the InjectionTarget inject method on the instance.
7. 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.
1. Call the InjectionTarget preDestroy method on the instance.
2. Call the InjectionTarget dispose method on the instance
3. 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.
---
For obtaining the BeanManager instance, I propose the following
change to Section 9.1 (Bootstrapping in Java EE Environments), added
as a third bullet to the list on p.358:
If the containing archive of the persistence unit is a bean archive, a
BeanManager instance must be made available by the container. The
container is responsible for passing this BeanManager instance via the
map that is passed as an argument to the createConstainerEntityManagerFactory
call. The map key used must be the standard property name
javax.persistence.bean.manager. [Final property name TBD.]