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 CallbackRegistry 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. Thanks! On Fri, Jan 22, 2016 at 3:28 PM Steve Ebersole <st...@hibernate.org> wrote: > 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. > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
