Hi,
I agree with Gunnar. Assuming that most (or at least the most popular) decency injection
frameworks have support for @PreDestroy (or equivalent),
it would be simpler to just state in the spec that it is the responsibly of the dependency
injection enabled ConstraintValidatorFactory to release validators
when the factory itself gets destroyed.
Does anyone have a good use case for an explicit
ConstraintValidatorFactory#releaseInstance or an example of a framework which would not be
able
to integrate with Bean Validation when releaseInstance would be removed. If not, I second
Gunnar's suggestions of removing the method and changing the spec.
--Hardy
On 3 Jan 2012, at 12:44 PM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi all,
The latest RI version [1] also implements the spec changes regarding the integration of
BV and CDI.
During implementation Hardy, Emmanuel and I got into a discussion regarding the lifecycle
of CDI-managed objects [2] which I'd like to continue.
The question is whose responsibility is it to release involved objects such as message
interpolator, traversable resolver or constraint validators. Generally we think objects
should be released by that party/code that created them.
This means:
1) objects created by the user and passed via bootstrap API: to be released by user
2) objects created by BV implementation (e.g. internal caches): to be released by BV
implementation
3) objects passed by CDI integration layer (e.g. CDI-enabled message interpolator etc.
based on BootstrapConfiguration): to be released by integration layer
I think 1) is not in our focus, let the user deal with it. For 2) we have
ValidatorFactory#close(). Interesting is 3). A CDI portable extension could make sure that
its created managed beans are properly released using CDI's pre-destroy hook [3].
But that way a CDI-enabled ConstraintValidatorFactory could also easily release all the
constraint validators it created:
CdiConstraintValidatorFactory implements ConstraintValidatorFactory {
public <T extends ConstraintValidator<?, ?>> T getInstance(Class<T>
key) {
//create validators. keep track of them.
}
@PreDestroy
public cleanUpValidators() {
//release created validators
}
}
That is, we'd again adhere to the principle that whoever creates objects has to
release them. When following this approach, we actually wouldn't need
ConstraintValidatorFactory#releaseInstance() anymore. I think this would be a good thing
as it IMO simplifies the contract between the BV provider and code integrating with it
(such as a CDI portable extension) and clarifies responsibilities.
In the spec we would describe that a CDI-enabled CVF has to release its validators when
it itself is going to be destructed and for ValidatorFactory#close(), that a BV provider
has to release its internal state but no objects passed to it.
One thing not possible with that approach is to release CV instances before the
application is shut down. The spec currently says that releaseInstance() is
"typically" invoked when the ValidatorFactory is closed, but AFAICS it leaves
room for releasing constraint validators also in between. OTOH I wouldn't know
when/how a BV provider would decide to do that.
Any thoughts?
--Gunnar
[1]
http://in.relation.to/Bloggers/HibernateValidator500Alpha2And431Final
[2]
https://hibernate.onjira.com/browse/BVAL-338
[3]
http://docs.oracle.com/javaee/6/tutorial/doc/gmgkd.html
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev