As far as I understand the issue, the classloader leaks are triggered because javax.validation.api has a bug, which is fixed in version 1.1.
I don't understand how using a container managed ValidatorFactory or a custom Resolver implementation could solve this problem?

Bean Validation makes it pluggable how validation providers (implementations such as Hibernate Validator) are found on the classpath via the ValidationProviderResolver SPI. The map causing the leak is (indirectly) used by the default resolver, therefore my thinking was that working with a different provider resolver should avoid the issue.

Since JBoss AS uses a specific provider resolver for bootstrapping the container managed VF, I had expected that using this factory would help, but as per your last response it doesn't. I don't really have an idea why, are you sure that you're not bootstrapping a VF yourself at another location? That said, you still might resort to the other option discussed, bootstrapping a VF yourself with a custom resolver.