Re: [hibernate-dev] JPA callback listeners and CDI
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?java...
[2] http://beanvalidation.org/1.1/spec/#d0e6698
2012/8/18 Steve Ebersole <steve(a)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(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev