Hi,
More below....
On 7/29/2011 2:13 AM, Emmanuel Bernard wrote:
> 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 think it would be cleaner not to have an annotation, but I'd like to hear
more from the group on this point.
> I can see three approaches actually:
> - no specific annotation: + most natural for CDI aware people
ok by me
> - 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
ugh.
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.
>
That is a better approach IMO
> 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
thanks,
-Linda