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
how Apache BVAL deals with this (via geronimo-validation-spec), e.g.
within TomEE?

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev