Hi there. My application is built on top of the Java Play Framework 2.8. It is actively uses async calls. Based on this https://www.playframework.com/documentation/2.8.x/JavaAsync#Using-HttpExecutionContext we need to supply concrete Executor to each async call to ensure that the classloader remains in scope.
I have to wrap native play.libs.concurrent.HttpExecutionContext to force it to do additional manipulations with a tread that will execute async call in addition to set proper classLoader. And it works perfectly, except cases when execution is delegated to the libraries which runs async calls under the hood.
Let’s take a look at an example: Play Memcached plugin
The current implementation of Memcached Play plugin uses play.cache.DefaultSyncCacheApi or play.cache.DefaultAsyncCacheApi. These default implementations execute Collables in a separate thread and this thread is obtained from a different (default) executor rather than which runs the initial async call.
So the question is: Is there a way ho to deal with such libraries in a case when we want to preserve classLoader (or something else like in my particular case)?