Feel free to modify the JBoss 4 code and post a patch to sf.net . I'm not entirely sure how ThreadGroup.destroy can help you, and even if it did I don't have an applet environment to test a fix.
I have a patch in the meantime which I'm testing. To my understanding the problem is caused that during the reload the static thread group is not yet destroyed when the new Applet is loaded and that therefor its threads are as well attached to the static threadgroup and are then destroyed (but this is a wild guess).
So I made a patch which uses a thread group per connection. By this I'm sure that there are no mixups. However for that I had to some classes in the org.jboss.mq.il.* packages so that the **ServerIL classes get the right connection to get the thread group from.
So far this works fine with the exception of the HAIServerIL in the cluster group. For this I haven't found a way yet to pass the connection.
Putting the patch on SF is a little difficult since I downloaded the sources for jboss 4.0.0, but if I compile them the jbossall-client.jar is slightly different in its size than the one from the binary distribution (maybe compiler options?). I tried as well to get the soureces from the cvs server (jboss-head) but got a strange directory structure which would not compile. Additionally when I compile the sources (the standard ones for 4.0.0) and run the tests I get a lot of failures (about 300). So I'm a little bit reluctant to pass the patch on before I have an environment which I feel confident with.
By the way, this is maybe a silly question, but what is the reason to have a threadgroup anyway? To my understanding the JVM in the plugin provides a standard one per applet thread. Is there a special reason for this thread group?
You can post the patch as it will be validated.
The ThreadGroup simply categorizes all of the jms thread into a logical grouping.
I do understand that the thread goup categorizes the jms threads. It's just so that I haven't seen any code which makes use of this situation, so its seems to be more a question of the concept than of a real usefulness. If that was the case I could easily replace the implementation of static method getThreadGroup of the connection with something like Thread.currentThread().getThreadGroup()., which would make the correction much easier.
Anyway I will post what I have done over the weekend.