[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