Without support-core, it works fine. An empty value is legal, as it is in java.util.logging generally.

Yoann can you still reproduce this? I could not. I started a dev version of support-core on 1.606, created a new log recorder, added a logger with the blank name (logging ALL), and saved. It produced lots of messages, to be sure, but Jenkins did not crash.

Jesse, I can't reproduce on a dev environment either (tried on 1.554 core). But I'm still able to reproduce by starting a standalone OSS 1.606 war and installing the latest support-core plugin manually.

Interesting…after having run 1.606, created the empty logger, deleted it, I tried to install Support Core (2.21) in the same session and got linkage errors, for example

java.lang.ClassCircularityError: java/util/Map$Entry
	at com.cloudbees.jenkins.support.impl.JenkinsLogs$CustomHandler.publish(JenkinsLogs.java:506)
	at java.util.logging.Logger.log(Logger.java:738)
	at java.util.logging.Logger.doLog(Logger.java:765)
	at java.util.logging.Logger.log(Logger.java:788)
	at org.eclipse.jetty.util.log.JavaUtilLog.debug(JavaUtilLog.java:108)
	at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:439)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
	at hudson.util.MaskingClassLoader.loadClass(MaskingClassLoader.java:62)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at jenkins.util.AntClassLoader.findBaseClass(AntClassLoader.java:1397)
	at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1074)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2693)
	at java.lang.Class.getDeclaredMethods(Class.java:1967)
	at org.jvnet.hudson.annotation_indexer.Index$2$1.fetch(Index.java:102)
	at org.jvnet.hudson.annotation_indexer.Index$2$1.hasNext(Index.java:72)
	at org.jvnet.hudson.annotation_indexer.SubtypeIterator.fetch(SubtypeIterator.java:18)
	at org.jvnet.hudson.annotation_indexer.SubtypeIterator.hasNext(SubtypeIterator.java:28)
	at hudson.init.TaskMethodFinder.discoverTasks(TaskMethodFinder.java:56)
	at hudson.init.InitializerFinder.discoverTasks(InitializerFinder.java:33)
	at hudson.PluginManager.dynamicLoad(PluginManager.java:479)
	at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1318)
	at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1121)
	at …

Seems to be a class loading order problem: this code loads Map.Entry for the first time (seems impossible!), which in turns triggers class loading, which the JVM rejects since we are already loading a class.

JENKINS-23442 shows a similar problem from a different Handler.

Easiest way to reproduce is to run 1.606 on a fresh $JENKINS_HOME, create a log recorder with an empty logger, shut down, ln -s …/support-core-plugin/target/test-classes/the.hpl to $JENKINS_HOME/plugins/support-core.jpl, and restart.

Have a fix for that mode. The empty logger spews over 3Mb of content, but it works. Unfortunately it does not work when creating the logger after installing the plugin.

And making a functional test for this is not going to work, I think—there is too little control over class loading. Could work as an acceptance test perhaps.

Reproduced in an acceptance test, but fixing is tedious. I do not know of a robust trick for preloading all classes that might be needed for a function, without actually running it.

In some sense the fault is in Jetty: ClassLoader implementations must be extremely conservative about calling into foreign code, and in particular they should not make any (synchronous) logging calls.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/com/cloudbees/jenkins/support/impl/JenkinsLogs.java
http://jenkins-ci.org/commit/support-core-plugin/43f0f84f2eee04623e464e9761c46915af6fd2bb
Log:
[FIXED JENKINS-27669] Force classes used by CustomHandler.publish to be loaded before we actually receive any log records.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/com/cloudbees/jenkins/support/impl/JenkinsLogs.java
http://jenkins-ci.org/commit/support-core-plugin/62ee0fdfa3325f121858644d6837312d2935cf57
Log:
Merge pull request #31 from jglick/ClassCircularityError-JENKINS-27669

JENKINS-27669 Prevent ClassCircularityError

Compare: https://github.com/jenkinsci/support-core-plugin/compare/db3e7f4e42ef...62ee0fdfa332

Code changed in jenkins
User: Jesse Glick
Path:
src/test/java/plugins/SupportCorePluginTest.java
http://jenkins-ci.org/commit/acceptance-test-harness/64c367031d50a70afcd9ea37c17a5de164f827c8
Log:
JENKINS-27669 Demonstrate ClassCircularityError before fix.

Code changed in jenkins
User: Oliver Gondža
Path:
src/test/java/plugins/SupportCorePluginTest.java
http://jenkins-ci.org/commit/acceptance-test-harness/6f66161fbde34a33942b83ce642b5d7f747a4203
Log:
Merge pull request #24 from jglick/ClassCircularityError-JENKINS-27669

JENKINS-27669 Demonstrate ClassCircularityError before fix

Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/2920150fe326...6f66161fbde3