Hi Linda and all,
Some feedback inline.
On 20 juil. 2011, at 21:51, Linda DeMichiel wrote:
> Greetings,
>
> We've gotten a number of requests for supporting CDI injection
> into entity listeners. I've been doing some iterating behind the
> scenes with Emmanuel and Pete Muir as to how we might address
> this.
>
> Pete pointed out the CDI SPIs which the persistence provider could use
> to make this work. Please see the following item in the Seam FAQ,
> http://seamframework.org/Documentation/HowDoIDoNoncontextualInjectionForAThirdpartyFramework
>
> This approach looks fairly straightforward and involves direct
> interaction on the part of the persistence provider with the CDI
> implementation. The entry point for this interaction is the CDI
> BeanManager, which the persistence provider can obtain from the Java
> EE container in JNDI as java:comp/BeanManager. Using the CDI SPIs,
> the persistence provider interacts with CDI to obtain instances of
> entity listener classes upon which CDI has performed injection.
>
> I'd therefore like propose the following additions to the JPA spec:
>
> * An entity listener class may be defined for CDI injection.
> A listener class that is intended to receive CDI injection must
> be annotated with the @BeanListener annotation (final annotation
> name TBD).
Like Craig Ringer, I don't think the mandatory annotation is necessarily a good idea. It's not inlined with the way CDI works. But provided that, such a bean can only be used by the JPA provider, it's probably not a show stopper.
I can see three approaches actually:
- no specific annotation: + most natural for CDI aware people
- a JPA specific annotation: my least favorite approach
- a marker annotation shared by all Java EE specs in the same situation @Injectable or something like that. This annotation could be hosted by CDI 1.1.
>
> * An entity listener class that is defined as a @BeanListener
> may specify PostConstruct and PreDestroy methods. These methods
> will be invoked by the provider after injection has taken
> place and before the entity listener instance is destroyed respectively.
+1
>
> * The persistence provider is only required to support CDI
> injection into listeners in Java EE container environments
> where the BeanManager is available in JNDI as java:comp/BeanManager.
> When this is not the case, @BeanListener classes will be
> ignored.
>
> The implementation referenced above is a strategy the persistence
> provider could use to implement this functionality, however, the
> spec would not prescribe any particular implementation.
I think we should go one step further and model the integration after section 3.6.2 ie Providing the ValidatorFactory
It's an model that has proved to work well both in SE and EE environments.
Of course we would remove the following
> If no ValidatorFactory instance is provided by the application, and if a Bean Validation provider is present in the classpath,
> the persistence provider must instantiate the ValidatorFactory using the default bootstrapping approach defined by the Bean Validation
> specification [8], namely Valida- tion.buildDefaultValidatorFactory().
unless the CDI guys come up with a portable SE API to bootstrap CDI.
>
> Finally, just to be very clear about this, an entity listener
> would thus be, in CDI terminology, an "unmanaged object".
> In other words, it would receive CDI injections, would not itself
> be available for injection into other CDI-managed beans.
+1