Hi Gunnar, Not sure if it can help. It seems that there is no caching: https://github.com/apache/bval/blob/bval-11/bval-jsr/ src/main/java/org/apache/bval/jsr/DefaultValidationProviderResolver.java 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. API, Ok for me. This is not a regression from BV 1.1 and there is a workaround until the next version of BV. keep the caching) but address the problem that we are caching things that we > don't know when to release from the cache. Totally agree. Marco On Tue, Jun 13, 2017 at 4:41 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > All, > > We've come across an issue related to bootstrapping BV providers in > application servers and I'd be interested in your ideas around it. > > The issue (BVAL-551 [1]) is about the javax.validation.Validation > class and the way it loads -- and caches -- validation providers. > j.v.Validation is essentially the only class in the entire API with > some actual implementation, so it's a bit special in that way. > > The validation-api.jar we provide alongside the RI maintains a cache > of resolved validation providers [2], this is to avoid repeated > look-ups via the service loader. In order to avoid any memory leaks, > this is implemented as a weak map with soft references as values. This > guarantees this map to be freed before an OutOfMemoryError occurs. > Nevertheless this can cause the memory to be retained for a long time, > esp. in an application server it may cause a reference to application > class loaders be retained if a validation provider has been obtained > from a deployment (again, eventually, that reference will be > released). > > For that case it'd be beneficial to have a way to pro-actively flush > that cache upon application undeployment. Now the thing is that the BV > API and the docs of j.v.Validation don't make any assumption on the > implementation and naturally there's no public notion of such caching > part of the API. Thus my preferred way for addressing this issue is to > declare a non-public method such as releaseProviderCache() in > j.v.Validation of our validation-api.jar. This method wouldn't be part > of the specified API. Interested application servers could call that > method reflectively as needed. > > In a future version of BV we could consider to make this a public API, > e.g. there could be Validation#getDefaultProviderResolver() and a new > default method ValidationProviderResolver#release() which could be > called to release any resources hold by a provider resolver (the cache > is hold within the default implementation of ProviderResolver). > Theoretically, this could also added to BV 2.0, but I feel it's a bit > rushed and I'd rather gather some experiences with this very special > purpose functionality before committing to it as part of the spec. > > Any thoughts on this one would be highly welcomed. Does anyone know > > Thanks, > > --Gunnar > > [1] https://hibernate.atlassian.net/browse/BVAL-551 > [2] https://github.com/beanvalidation/beanvalidation-api/blob/ > master/src/main/java/javax/validation/Validation.java#L317 > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >