This is needed to avoid a thread context classloader leak, as described in http://jira.jboss.com/jira/browse/JGRP-752.

This issue obbsoletes http://jira.jboss.com/jira/browse/JGRP-752.

[email Brian Stansberry]

This proved problematic. Problem is that Protocol exposes getThreadFactory() but not setThreadFactory. Result is my approach of getting the DefaultThreadFactory you create, wrapping it in my class and then passing it back via the setter doesn't work. And I suspect you don't want to change an API by adding a setThreadFactory to Protocol.

Attached are a couple patches that take a different approach. Idea is your thread factories and thread pools expose an interface to allow me to register for a callback when your create a thread or return one to the pool after use. With this I don't need any setter and also don't have to keep my wrapper class in sync w/ future changes to your stuff. I just call a getter for each factory and pool, and register for callbacks.

First one is the fundamental one and applies this concept to DefaultThreadFactory and TimerScheduler.

Second one tweaks TP to 1) have the default and oob thread pools invoke the callbacks and 2) create them in init. Creating them in init instead of as part of connect() lets my factory get the thread pools your code creates and register for callbacks before returning the channel. If I can use the pools you create there's no need to duplicate/keep in sync with your thread pool creation logic.