Some thread pool implementation will immediately create a new thread if work is submitted and there is not enough threads available to handle it. This newly created thread will inherit the access control context of the thread that is submitting the work, which essentially means that thread pool threads have a random access control context.

This is the root cause of UNDERTOW-102, and likely other security manager related failures as well.

I think that the best way to fix this is in the thread pool itself, as it should create the thread in a privileged block. We obviously cannot do this for JDK thread pools however.