Anyone remember the back-story
If I read it correctly, it is looking at annotations on the entity seeing
if any of those annotations are in turn annotated with @EntityListeners.
On Fri, Jan 22, 2016 at 3:38 PM Steve Ebersole <steve(a)hibernate.org> wrote:
If it matters, my plan is as follows...
Currently JpaIntegrator is the central point for this processing. The
general premise is that it builds a CallbackRegistry, a ListenerFactory
and a CallbackProcessor. It then uses the CallbackProcessor and ListenerFactory
to populate the CallbackRegistry. This part is the crux of the problem
with HHH-8076 as after this JpaIntegrator call it is expected that CallbackRegistry
be fully initialized (all Callbacks resolved and ready to go).
So the plan is to instead invert these relationships to where we build a
that is aware of the ListenerFactory and CallbackProcessor (actually I
think CallbackProcessor can go away). This is the point in the suggested
solution described for HHH-8076 where we'd check the BeanManager to see if
it is a BeanManagerExtension and decide whether to delay the
initialization. If that plan causes trouble for anyone, please speak up
asap. If not, I'll proceed.
On Fri, Jan 22, 2016 at 3:28 PM Steve Ebersole <steve(a)hibernate.org>
> As part of the work on HHH-8076 for ORM 5.1 I am going to have to change
> up, in some fashion, some or all of the following internal/spi contracts :
> * org.hibernate.jpa.event.spi.jpa.Callback
> * org.hibernate.jpa.event.spi.jpa.CallbackRegistry
> * org.hibernate.jpa.event.spi.jpa.ListenerFactory
> * org.hibernate.jpa.event.internal.jpa.CallbackProcessor
> I need to know whether any integrations either use any of these or
> provide custom impls for any of them.