[hibernate-dev] HHH-8076 - CDI-capable entity listeners

[Steve Ebersole]

BTW... there is also discussion of a delayed approach that would be based
on a setting.

This setting would essentially tell Hibernate to delay CDI access until
first use of a Listener.  I had resisted this approach because it delays
"deployment errors" (exceptions that really ought to stop the deployment)
until runtime.

The "win" for this approach however is that it would work in both 5.0 and
5.1.

So I think I will add that option, unless anyone has objections.


On Mon, Jan 25, 2016 at 12:02 PM Steve Ebersole <steve at hibernate.org> wrote:

> 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 at hibernate.org>
> 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 at hibernate.org> 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 at 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 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 at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>