ResteasyProviderFactory uses a singleton for storing its default instance, likely as a consequence of JAX-RS RuntimeDelegate relying on a similar approach.
On server side, when the "deployment sensitive factory" option is enabled, the ThreadLocalResteasyProviderFactory implementation is used to differenciate the instance serving each deployment, but still, that can lead to a clash when a thread pool is in place.
ResteasyProviderFactory.getInstance() is invoked in multiple places in the code, on client side that's used as a trick for getting the instance for the server in which the client is running (in case of in-container clients).
I believe we should bind the application ResteasyProviderFactory instance to the application classloader, by assuming that's normally set as thread context classloader. The singleton should only be treated as fallback.