Hi Linda,
it was actually my suggestion so: +1 for Pete's suggestion :-)
Added value:
A CDI-managed entity listener could re-send changed entities as CDI-events, expose them via REST etc. Now the EntityListener is managed by JPA and can be only hardly integrated with CDI / EJB,
On 21.06.2011, at 22:50, Linda DeMichiel wrote:
> Assuming you all have read the message from Pete Muir which I
> forwarded earlier.....
>
> Entity listeners are not container-managed objects in the sense of
> EJBs or CDI managed beans, and do not have their own independent
> component environment. They are managed by the persistence provider,
> and when they are invoked within JavaEE their naming environment is
> that of the calling component.
>
> To support injection in them, they would presumably need to become
> container-managed objects (as well), and we would need to define their
> lifecycle, add support for PostConstruct, PreDestroy, etc.
>
> While I think I can understand your motivation for wanting this
> functionality, I'm not convinced of the tradeoff in terms of the
> added complexity.
>
> I'd like to hear from others on this point though.
>
> thanks,
>
> Linda
>
>
> On 6/21/2011 5:18 AM, Adam Bien wrote:
>> Hi *
>>
>> EntityListeners should be integrated with CDI / EJB 3.2. It means: Java EE 7 DI should work in EntityListener classes.
>> An EntityListener could be annotated with @Singleton / @Stateless / @RequestScoped etc. (everything what is stateless)
>>
>> We should extend the sentence: "Entity listeners are stateless. The lifecycle of an entity listener is unspecified" at
>> the page 95 of the Expert Group Draft 2. to "The lifecycle of an entity listener is unspecified in unmanaged
>> environments. An EJB 3.2 @Stateless, @Singleton or CDI managed bean can also receive callback events",
>>
>> What do you think?
>>
>> adam