Jochen Theodorou wrote:

Maybe I misunderstand what you mean. The bootstrap class loader will load java.lang.Thread.

What I saw as I did the memory analysis on this is that the thread's contextClassLoader is the WebappClassLoader, and that is because the thread which creates this one has the WebappClassLoader for its contextClassLoader and the new thread takes its creator's ccl.

def script = """ def thread = new Thread ({ sleep(Integer.MAX_VALUE) }) thread.daemon = true thread.start() """ def registry = GroovySystem.metaClassRegistry 100000.times { def shell = new GroovyShell(this.class.classLoader) shell.evaluate script if (it%100==0) { println "#"*80 println "constant meta classes: ${registry.constantMetaClassCount}" println "weak meta classes: ${registry.weakMetaClasses.size()}" } }

Perhaps the logic you described would work for discriminating among the various profiles; I'm nowhere near familiar enough with Groovy to have an opinion about that. But is it reasonable to provide a public API which an application or a container could invoke to close down Groovy in an orderly manner which would include running down this thread?

Granted, the developer of a web app deployed to an app server would need to have a ServletContextListener which detects when the web app is stopping and could then invoke the Groovy close-down method. That does not seem to be too much of a burden, considering the complexity of having Groovy deciding itself which profile is in effect. Just a thought.