I don't think this is a viable option.
ThreadGroup.setDaemon(...) was deprecated for
removal in JDK16.
Thanks; good to know.
In general, we should avoid creating a new ThreadGroup where the parent thread is (or
can
be) an application thread.
+1
For the clustering subsystems, I created
https://github.com/wildfly/wildfly/pull/17194,
using the ThreadGroup of the calling thread for use cases that may originate from an
application thread (akin to Matej's PR). For use cases where a distinct ThreadGroup
is desired and the caller thread is known to be an MSC thread, I used a static
ThreadFactory instance.
Thanks; I'll have a look.