If you add the private clearValidationProviderCache() method, we can add WildFly code to call it at undeploy time, later if there is a public equivalent, we can switch to calling that. I still think that it would be good to get feedback from others in the BV community, as well, about whether there should be a standard way to clear the cache in different container/frameworks.

One thing I can see us doing is to remove the current caching scheme from the default provider resolver. And if people actually need to cache resolved providers, they'd have to plug in their own custom provider resolver (and would be in charge of clearing its internal state after usage).

That is another possible path, I assume by default then, WildFly + other container environments would by default, not perform as well, until a custom provider resolver is implemented. My preference is to poll the BV community/expert group and see what others might be interested in, before introducing a custom provider resolver.

My vote is to keep good performance by default (e.g. keep the caching) but address the problem that we are caching things that we don't know when to release from the cache.

One other complaint that I have about calling private methods across components, it reminds me of some proprietary vendor (database/OS) approaches, where their own applications used internal APIs that most 3rd party applications didn't know about, which gave the vendor an unfair advantage. I suppose that we could address this by describing the clearValidationProviderCache() method in some HV documentation, if you agree that could help integration on other platforms.