<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      +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.<br>
      <br>
      Seb<br>
      <br>
      On 03.12.2012 12:44, Gunnar Morling wrote:<br>
    </div>
    <blockquote
cite="mid:CADGJaX-h9-dyizqVak0MuhhGQQRPRtVgZX+gDK_skp2YJs2ecQ@mail.gmail.com"
      type="cite">Hi all,
      <div><br>
      </div>
      <div>The latest RI version [1] also implements the spec changes
        regarding the integration of BV and CDI.</div>
      <div><br>
      </div>
      <div>During implementation Hardy, Emmanuel and I got into a
        discussion regarding the lifecycle of CDI-managed
        objects&nbsp;[2]&nbsp;which I'd like to continue.&nbsp;</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>This means:</div>
      <div><br>
      </div>
      <div>1)&nbsp;objects created by the user and passed via bootstrap API:
        to be released by user</div>
      <div>
        <div>2) objects created by BV implementation (e.g. internal
          caches): to be released by BV implementation</div>
      </div>
      <div>3)&nbsp;objects passed by CDI integration layer (e.g. CDI-enabled
        message interpolator etc. based on BootstrapConfiguration): to
        be released by integration layer</div>
      <div><br>
      </div>
      <div>I think 1) is not in our focus, let the user deal with it.
        For 2) we have ValidatorFactory#close().&nbsp;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].</div>
      <div><br>
      </div>
      <div>But that way a CDI-enabled ConstraintValidatorFactory could
        also easily release all the constraint validators it created:</div>
      <div><br>
      </div>
      <div>CdiConstraintValidatorFactory implements
        ConstraintValidatorFactory {</div>
      <div><br>
      </div>
      <div>&nbsp; public&nbsp;&lt;T <span class="">extends</span>
        ConstraintValidator&lt;?, ?&gt;&gt; T getInstance(Class&lt;T&gt;
        key) {</div>
      <div>&nbsp; &nbsp; //create validators. keep track of them.&nbsp;</div>
      <div>&nbsp; }</div>
      <div><br>
      </div>
      <div>&nbsp; @PreDestroy</div>
      <div>&nbsp; public cleanUpValidators() {</div>
      <div>&nbsp; &nbsp; //release created validators</div>
      <div>&nbsp; }</div>
      <div>}</div>
      <div><br>
      </div>
      <div>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&nbsp;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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>Any thoughts?</div>
      <div><br>
      </div>
      <div>--Gunnar</div>
      <div><br>
      </div>
      <div>[1]&nbsp;<a moz-do-not-send="true"
href="http://in.relation.to/Bloggers/HibernateValidator500Alpha2And431Final">http://in.relation.to/Bloggers/HibernateValidator500Alpha2And431Final</a></div>
      <div>[2]&nbsp;<a moz-do-not-send="true"
          href="https://hibernate.onjira.com/browse/BVAL-338">https://hibernate.onjira.com/browse/BVAL-338</a></div>
      <div>[3]&nbsp;<a moz-do-not-send="true"
          href="http://docs.oracle.com/javaee/6/tutorial/doc/gmgkd.html">http://docs.oracle.com/javaee/6/tutorial/doc/gmgkd.html</a></div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
beanvalidation-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>