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.

Anyone remember the back-story on org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor#useAnnotationAnnotatedByListener? 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&gt; 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 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 <steve(a)hibernate.org&gt; > 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I have been in constant discussion with Scott about this. I developed proposal after my discussions with him. Ultimately we believe the solution is an extension to CDI. I developed this with that in my mind's eye. Scott will be taking my work so far and trying to finish it (do the WildFly piece) this afternoon. After we are all done we will suggest this as an extension to CDI proper. On Mon, Jan 25, 2016 at 11:41 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > I checked : > - Hibernate OGM > - Hibernate Search > - Hibernate Validator > - WildFly > > And none are using the listeners you listed. In the case of WildFly, I > don't know of course about all the frameworks which are included in > there. > > Sanne > > On 22 January 2016 at 23:58, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > Anyone remember the back-story > > on > org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor#useAnnotationAnnotatedByListener? > > > > 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&gt; > 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 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 <steve(a)hibernate.org&gt; > >> 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >