• Bug
  • Status: Resolved
  • 1 Critical
  • Resolution: Won't Fix
  • DSO:L1
  • teck
  • Reporter: teck
  • April 17, 2007
  • 1
  • Watchers: 3
  • August 21, 2013
  • August 21, 2013

Description

Could not load Logmanager “com.sun.enterprise.server.logging.ServerLogManager” java.lang.ClassNotFoundException: com.sun.enterprise.server.logging.ServerLogManager at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.util.logging.LogManager$1.run(LogManager.java:166) at java.security.AccessController.doPrivileged(Native Method) at java.util.logging.LogManager.(LogManager.java:156) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.init(ClassProcessorHelper.java:405) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.systemLoaderInitialized(ClassProcessorHelper.java:795) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1327) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1286)

Glassfish relies on the thread context classloader being set to a glassfish loader when jdk logging is initialized. It is hard to not intialize jdk logging (usually a side effect of using some other built in java type (eg. HttpUrlConnection)). Furthermore, in TC we explicitly initialize jdk logging very early in the VM startup to workaround the known deadlocks that exist in LogManager.

There is an unsupported workaround available here: http://svn.terracotta.org/svn/forge/projects/glassfish-logging

Comments

Fiona OShea 2007-04-23

Is this already resolved?

Tim Eck 2007-06-13

I’m not 100% sure what the impact of this exception is. Is definitely printed, and from looking at the JDK logging code, what ends up happening is the default logging manager implementation is used (instead of the glassfish one). I’m sure there is some downside to that, but not sure how bad it is

Tim Eck 2009-05-12

One downside is that all logging ends up going to the console instead of where glassfish wants to naturally place its logs. I expect the formatting of the log message is also different. For both of these reasons any tools that depend on the location/format of glassfish logs will be broken

Walter Harley 2009-05-13

As a workaround, would it suffice to put the glassfish logger classes on the the boot classpath? Or do they bring in too much other stuff?

Tim Eck 2009-05-13

It’s worth a try for sure (thanks!) but I suspect it could require more classes than desired and might introduce some other problems (like ClassCastException or LinkageError)

Fiona OShea 2009-05-27

Also reported on forum post http://forums.terracotta.org/forums/posts/list/2179.page

Chris Dennis 2009-06-03

Not sure if people have seen these, but it appears the Glassfish community is aware of the issue:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=1409 https://glassfish.dev.java.net/issues/show_bug.cgi?id=3390 https://glassfish.dev.java.net/issues/show_bug.cgi?id=4551

In 3390 they basically admit that the logging system (and their mbean server) is b0rken. I did also read elsewhere (can’t find it now) that there was an attempt to move the logging stuff into a separate jar that could be put on the system classpath to solve this class of problem - this apparently turned into a complete nightmare as their logging is tied way too tightly to tons of their core classes.

Options that I see as available:

  1. Provide some kind of proxy LogManager…
  2. Provide a different fix for the original deadlock issues that prompted the need for an early class load here.
  3. Wait for glassfish guys to fix (is it perhaps fixed in 3?)

Tim Eck 2009-06-03

I’m actually talking to a sun engineer about this issue tommorow. We’re looking into something like #1.

Regarding #2 even if we didn’t eagerly initialize LogManager in our code, it is still really easy to use something else that ends up calling on LogManger (like URL.openConnection()) which is something we use for resolving config over http. Forget to mention that JDK7 is supposed to fix the LogManager deadlock – not that it helps us much.

Ronnie Vuine 2009-08-19

Tim, any results? Please let me know if this is going to be fixed in 3.1 – it’s a showstopper for us, we need proper GF logging, including rotation. I’d hate to see us give up on Terracotta (at least for now) because of something silly like this.