The implementation around ObjectWriterModifier is designed on top of a ThreadLocal in com.fasterxml.jackson.jaxrs.cfg.ObjectWriterInjector . That is basically wrong, as it relies on the assumption that the ResteasyJackson2Provider will be running in the same thread the user is setting the modifier in.
As a matter of fact, after having disabled a bunch of tests in resteasy testsuite against wildfly 13 (for unrelated reasons) I started reproducing failures on Travis CI because of this problem, which basically proves that the "solution" is sensible to test execution order and the container thread pool implementation.
We need to think about a different solution, perhaps with the modifier being stored per-deployment-classloader instead of per-thread (note this affects documentation).