[bv-dev] Do we need ConstraintValidatorFactory#releaseInstance()?
Sebastian Thomschke
sebastian.thomschke at web.de
Mon Dec 3 11:47:12 EST 2012
Hi,
+1 for removing the method and changing the spec accordingly. Externally
instantiated objects and passed to the BV impl should not be released by
the BV impl.
Seb
On 03.12.2012 12:44, Gunnar Morling 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121203/f8fb7bf4/attachment.html
More information about the beanvalidation-dev
mailing list