It looks like our problems with GlassFish have just began. Whereas the installation issues found a quick solution, we almost immediately ran into a year old problem, reported by the guys from YourKit. The issue is with with loading the “ServerLogManager” class (see also this forum post).

A quick foray into the JDK source shows that log managers are loaded from the system classloader and then from the Thread context classloader. Of course in case of GlassFish the manager is not in the system classpath, but instead found via the context classloader. However the context classloader is set only after GlassFish initialization begins, so any agents that need to access Java API before that are left in the void (both YourKit Profiler and JavaRebel feature instrumentation agents, which are initialized before the actual application begins execution).

To be fair this is a definite failing in the JDK log manager resolution logic. Since log managers are determined using a system property it is dangerous to assume that their resolution is in any particular context (which context classloader obviously implies). GlassFish just happened to hit this case, since very few others use a custom log manager for the JDK logging. The only reasonable fix I can see here is lifting the ServerLogManager to the system classpath and decoupling it from the child classloaders.

For those who can’t wait until it’s fixed it seems that adding “-Drebel.disable_update=true” to the jvm-options also fixes the problem for JavaRebel (it disables the update notification, which is apparently the only thing in JavaRebel that utilizes JDK logging).

This entry was posted on Wednesday, December 19th, 2007 at 10:35 pm and is filed under blog. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.