[hibernate-dev] JPA callback listeners and CDI

[Gunnar Morling]

The idea was to have some sort of dependency inversion.

So instead of the JPA provider working directly with BeanManager,
there could be an interface EntityListenerFactory defined in the JPA
spec (basically what you already have with ListenerFactory, only
defined by the spec) and a way for configuring/plugging in a factory
implementation when bootstrapping JPA.

It would be task of the Java EE container then to plug in an
EntityListenerFactory which creates CDI-enabled listeners (basically
your BeanManagerListenerFactory, only that it's not implemented within
the JPA provider, but is passed by the container). That way a JPA
provider wouldn't have direct dependency on CDI, only to the
EntityListenerFactory interface defined by JPA.


2012/8/19 Steve Ebersole <steve at hibernate.org>:
> Not really sure what you are suggesting really.  But JPA is very specific in
> how this is supposed to happen.  Providers are passed an instance of
> BeanManager.  If present, the JPA provider must use the BeanManager API.
>
>
> On Sat 18 Aug 2012 05:06:30 PM CDT, Gunnar Morling wrote:
>>
>> Hi Steve,
>>
>>> using JPA now has a dependency
>>> on the CDI API being available on the classpath.  We need to decide if
>>> that is unreasonable.
>>
>>
>> I guess most Spring users (or more generally, people not using CDI)
>> wouldn't really like this dependency.
>>
>> In BV 1.1, we have a similar requirement: CDI support shall be added
>> for ConstraintValidator implementations. With
>> ConstraintValidatorFactory [1], we do have an SPI though, which allows
>> to plug in factories for the creation of validators.
>>
>> For the CDI integration the idea is, that the Java EE container should
>> provide and configure a factory implementation which creates
>> CDI-enabled validators [2]. That way BV implementors don't have to
>> deal with CDI specifics such as BeanManager directly.
>>
>> Maybe it could be done in a similar way for entity listeners?
>>
>> --Gunnar
>>
>> [1]
>> http://docs.jboss.org/hibernate/stable/beanvalidation/api/index.html?javax/validation/ConstraintValidatorFactory.html
>> [2] http://beanvalidation.org/1.1/spec/#d0e6698
>>
>>
>> 2012/8/18 Steve Ebersole <steve at hibernate.org>:
>>>
>>> Recently I just finished up adding JPA 2.1 support for CDI injection of
>>> callback listeners.  Couple of things about this:
>>>
>>> 1) Took this opportunity to refactor and clean up a lot of this code.
>>> On benefit of this was I added a feature now where after transaction
>>> hooks are not added as part of ActionQueue processing unless registered
>>> listeners say it is needed for that particular entity type!  This is
>>> something users have been asking for for quite some time.  So thats a
>>> good win.  This is both for Envers and HEM.
>>>
>>> 2) The way this is currently implemented, using JPA now has a dependency
>>> on the CDI API being available on the classpath.  We need to decide if
>>> that is unreasonable.  The other option is to handle it like we do for
>>> BeanValidation and use messy reflection to isolate the dependency.
>>>
>>>
>>> --
>>> steve at hibernate.org
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> steve at hibernate.org
> http://hibernate.org