The classloader set in the current threads class loader leaks from the UndertowContainerProvider to the XnioWorker when the former is creating the XnioWorker.

Because the tccl is always equal to the deployed application cl, it means that this cl is going to be set in the XnioWorker context class loader for good, and it will remain there even after the application is undeployed.

To understand why the tccl carries over to the XnioWorker, it is important to remember that the XnioWorker is a java.lang.Thread object. In the constructor of the thread, the tccl of the parent thread is read and, if non-null, it is set as the tccl of the thread being created. So, that's how the application class loader ends up in the XnioWorker tccl field. This class loader is used by any other application using the same XnioWorker, and notice that the XnioWorker is shared across multiple applications. The result of this could be harmless if other deployed applications don't contain classes with the same name as in the leaked cl deployment. But if they do, errors will occur, as the class loader is going to attempt to use the class belonging to the first deployed applications when requested to load a class with the same name, affecting specially the class loading of dynamic proxies in that application.