JAVA: SecurityException on ThreadGroup.getParent()

I have some pretty boilerplate Java code that does a while loop with a tg.getParent() to get the root thread group. This has been working for several months on four different environments (one Windows and three Linux). Recently we added a fifth environment for our Accessment Validation testing. This environment is supposed to be a replica of our production environment as much as possible. The developers have very limited access to this system, and it's been a multi-week process getting the system set up by our hosting group to have all the correct permissions and properties.

Just about everything is now working, however today, when the tester went to the part of the application that exercises the getRootThreadGroup() method mentioned above, the call to ThreadGroup.getParent() apparently threw a SecurityException. I don't have a lot of details because at the moment I haven't been able to locate the application log file. But I am 99.99% sure that a SecurityException occurred here. I've looked at the javadoc for SecurityException and getParent() and checkAccess(), etc, but none of it is making a lot of sense to me.

Can anyone think of a simple reason why this new environment would cause our application to throw a SecurityException on this call when this has never been observed on any other environments (and the code definitely gets executed without exception on all the other environments)? My gut feeling is that somehow the runtime user for the application doesn't have permissions to "something" ...

Oh, it's running on a Bea Weblogic server with java 1.6 (jrockit-jdk), but it should be configured exactly the same as the other environments.

Thanks for any he开发者_JAVA技巧lp.

Sounds like a security manager is being used. If you write a simple program to execute Thread.currentThread().getThreadGroup().getParent() and run it with -Djava.security.manager, you will see:

Exception in thread "main" java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThreadGroup)

Never mind. I found that the problem was actually a missing database column. It took me two hours this morning to finally locate the log, and once I found that, it was very simple to find the actual problem.