ClassLoader Leak when adding spring-cloud-context dependency when deployed as a War

I am currently trying to create my own version of the spring-boot-admin. Since we are still using a standalone Tomcat on our servers I am creating a war package. To discover memory leaks with regard to ClassLoader leaks we have created an integration test: https://github.com/evosec/tomcat-classloader-leak-test

Sadly the test fails for the spring-boot-admin. I could boil it down to the spring-cloud-context 1.2.0 dependency. I have created a demo project that demonstrates the issue: https://github.com/ArloL/spring-cloud-context-classloader-leak-demo

Note that master runs successfully and the spring-cloud-context branch fails.

The only difference is the added spring-cloud-context dependency: https://github.com/ArloL/spring-cloud-context-classloader-leak-demo/compare/master...spring-cloud-context

I have tried analyzing the heap dump with VisualVM as described in https://cdivilly.wordpress.com/2012/04/23/permgen-memory-leak. Be aware that the query is a bit different nowadays select x from org.apache.catalina.loader.ParallelWebappClassLoader x. This sadly did not give any helpful results.

Then I tried adding the classloader-leak-prevention-servlet3. Sadly this does not change the test result: https://travis-ci.org/ArloL/spring-cloud-context-classloader-leak-demo/builds/233563888. There is also no difference in the heap dump.

I do realize that deployment inside a standalone Tomcat is not in the focus of a spring-cloud dependency but maybe there is a bug (e.g. instantiated Servlet that is not properly destroyed) that is presenting itself due to this test. Maybe someone else has an idea about what's going on here. Thanks a lot :)

Start with the linked spring-cloud-context-classloader-leak-demo and its integration test, comparing the master and spring-cloud branches to reproduce the failure under standalone Tomcat. Trace which spring-cloud-context lifecycle entry points retain the web application's class loader. Done means identifying the leak mechanism and documenting or validating a fix against the classloader leak test.