I suggest this be controlled with a configuration flag rather than relying on the presence/absence of an mbean server. The behavior of moving an mbean through create/start/stop/destroy is not inherent in an mbean server; it's a special function of JBoss AS. So, you could have JBC running in the presence of an mbean server that would not call stop/destroy for you. Theoretically, you could also have JBC running in a pure microcontainer version of JBoss AS 5 where there is no mbean server. But that AS would still have its own ShutdownHook that takes care of create/start/stop/destroy and would not want JBC's own hook getting in the way.
This is not an urgent thing; in the real world JBoss AS always has an mbean server, so the existing JBCACHE-1204 fix stops the problem of the JBC shutdown hook screwing up an AS shutdown.
Another issue with the shutdown hook I'm seeing with Hibernate testing is that the hook doesn't get removed in internalStop(). JBC should keep a ref to the hook and remove it in internal stop; otherwise:
1) The hook executes at vm shutdown even though the cache was previously stopped/destroyed. That currently just causes a DEBUG log, but it's prone to breakage.
2) Until that happens you've leaked a ref to the CacheImpl to the shutdown hook thread.
Might want to make the hook impl a bit more sophisticated so internalStop() can check if it is executing -- i.e. don't call Runtime.removeShutdownHook if it is the hook itself that calls internalStop().