<div dir="ltr"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Hi Gunnar,</span><div><br></div><div>> how Apache BVAL deals with this (via geronimo-validation-spec), e.g.</div><div>> within TomEE?<br><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Not sure if it can help. It seems that there is no caching:</span><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><a href="https://github.com/apache/bval/blob/bval-11/bval-jsr/src/main/java/org/apache/bval/jsr/DefaultValidationProviderResolver.java" target="_blank">https://github.com/apache/<wbr>bval/blob/bval-11/bval-jsr/<wbr>src/main/java/org/apache/bval/<wbr>jsr/<wbr>DefaultValidationProviderResol<wbr>ver.java</a></span></div><div><br></div><div><br></div><div>> Nevertheless this can cause the memory to be retained for a long time,</div><div>> esp. in an application server it may cause a reference to application</div><div>> class loaders be retained if a validation provider has been obtained<br>> from a deployment<br><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">I think in most of the use cases there is one application per server/container and the server/container is restarted at each deploy. For these cases there is no issue.</span></div><div><br></div><div><font color="#000000" face="Helvetica"><span style="font-size:12px">> </span></font>Thus my preferred way for addressing this issue is to</div><div>> declare a non-public method such as releaseProviderCache()</div><div>> [...] In a future version of BV we could consider to make this a public API,<br><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Ok for me. This is not a regression from BV 1.1 and there is a workaround until the next version of BV.</span></div><div><br></div><div><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">> [Scott, from JIRA] My vote is to keep good performance by default (e.g. keep the caching) but address the problem that we are caching</span><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"> </span><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">things that we > don't know when to release from the cache.<br></span><br>Totally agree.<br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Marco</span><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 4:41 PM, Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br>
<br>
We've come across an issue related to bootstrapping BV providers in<br>
application servers and I'd be interested in your ideas around it.<br>
<br>
The issue (BVAL-551 [1]) is about the javax.validation.Validation<br>
class and the way it loads -- and caches -- validation providers.<br>
j.v.Validation is essentially the only class in the entire API with<br>
some actual implementation, so it's a bit special in that way.<br>
<br>
The validation-api.jar we provide alongside the RI maintains a cache<br>
of resolved validation providers [2], this is to avoid repeated<br>
look-ups via the service loader. In order to avoid any memory leaks,<br>
this is implemented as a weak map with soft references as values. This<br>
guarantees this map to be freed before an OutOfMemoryError occurs.<br>
Nevertheless this can cause the memory to be retained for a long time,<br>
esp. in an application server it may cause a reference to application<br>
class loaders be retained if a validation provider has been obtained<br>
from a deployment (again, eventually, that reference will be<br>
released).<br>
<br>
For that case it'd be beneficial to have a way to pro-actively flush<br>
that cache upon application undeployment. Now the thing is that the BV<br>
API and the docs of j.v.Validation don't make any assumption on the<br>
implementation and naturally there's no public notion of such caching<br>
part of the API. Thus my preferred way for addressing this issue is to<br>
declare a non-public method such as releaseProviderCache() in<br>
j.v.Validation of our validation-api.jar. This method wouldn't be part<br>
of the specified API. Interested application servers could call that<br>
method reflectively as needed.<br>
<br>
In a future version of BV we could consider to make this a public API,<br>
e.g. there could be Validation#getDefaultProviderR<wbr>esolver() and a new<br>
default method ValidationProviderResolver#rel<wbr>ease() which could be<br>
called to release any resources hold by a provider resolver (the cache<br>
is hold within the default implementation of ProviderResolver).<br>
Theoretically, this could also added to BV 2.0, but I feel it's a bit<br>
rushed and I'd rather gather some experiences with this very special<br>
purpose functionality before committing to it as part of the spec.<br>
<br>
Any thoughts on this one would be highly welcomed. Does anyone know<br>
how Apache BVAL deals with this (via geronimo-validation-spec), e.g.<br>
within TomEE?<br>
<br>
Thanks,<br>
<br>
--Gunnar<br>
<br>
[1] <a href="https://hibernate.atlassian.net/browse/BVAL-551" rel="noreferrer" target="_blank">https://hibernate.atlassian.ne<wbr>t/browse/BVAL-551</a><br>
[2] <a href="https://github.com/beanvalidation/beanvalidation-api/blob/master/src/main/java/javax/validation/Validation.java#L317" rel="noreferrer" target="_blank">https://github.com/beanvalidat<wbr>ion/beanvalidation-api/blob/<wbr>master/src/main/java/javax/<wbr>validation/Validation.java#<wbr>L317</a><br>
______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss<wbr>.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/beanvalidation-dev</a><br>
</blockquote></div><br></div></div></div>