Kohsuke Kawaguchi wrote on the hudson list:

Looks like a bug in Gradle to me. I bet it's not passing the proper
ClassLoader and relying on the incorrect assumption that the context
classloader can load what it needs.

If you can report the issue to Gradle and let us know where you filed
the ticket, I can explain to them what I think is going wrong.

While I haven't looked into JavaUtilLoggingConfigurer, given that j.u.l.LogManager consults the context classloader to load org.apache.juli.ClassLoaderLogManager, it is the responsibility of JavaUtilLoggingConfigurer to ensure that j.u.l.LogManager can find o.a.j.ClassLoaderLogManager — that involves pushing the current thread context classloader aside, setting it to the right one while you let j.u.l load it, then poping it back.

In Hudson (and in many other multi-classloader environment such as Ant, Maven, IDEs), thread context classloader doesn't have anything to do with the classloader that loaded the class that's currently executing. I believe that is causing the problem.

It looks like j.u.l.LogManager is attempting to load a manager class specified by the java.util.logging.manager system property. Gradle does not set this property. One possibility is that this is being specified when Hudson launches Gradle - either explicitly via a -D command-line option, or accidentally by inheriting the Hudson process' JAVA_OPTS or GRADLE_OPTS environment variables.

Any chance you can get a debug log showing the command-line and environment variables that Hudson is using to launch Gradle?

Here is the first part of the hudson console. If you need the rest, let me know and I can paste it.

Also, I am using the gradle plugin for hudson (http://wiki.hudson-ci.org/display/HUDSON/Green+Balls). FYI in case changes are needed there.

Started by user anonymous Updating http://svn.itsolut.com/svn/its/branches/next_gen/app-overlord At revision 5347 no change for http://svn.itsolut.com/svn/its/branches/next_gen/app-overlord since the previous build [app-overlord] $ cmd.exe /C gradle.bat -d -s clean uploadArchives && exit %%ERRORLEVEL%%
Could not load Logmanager "org.apache.juli.ClassLoaderLogManager" java.lang.ClassNotFoundException: org.apache.juli.ClassLoaderLogManager at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.util.logging.LogManager$1.run(LogManager.java:168) at java.security.AccessController.doPrivileged(Native Method)

Is it possible for Hudson to show the environment variables it will use to launch Gradle?

Also, which version of the Gradle Hudson plugin are you using? It looks like 1.4 might have some fixes in it to stop Hudson's $JAVA_OPTS being inherited by the Gradle process.

Started by user anonymous
Updating http://svn.itsolut.com/svn/its/branches/next_gen/app-sso
At revision 5353
no change for http://svn.itsolut.com/svn/its/branches/next_gen/app-sso since the previous build
[app-sso] $ cmd.exe /C gradle.bat -S clean uploadArchives && exit %%ERRORLEVEL%%

C:\Users\Chris Hane\.hudson\jobs\app-sso\workspace\app-sso>set
ACTION=start
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\Chris Hane\AppData\Roaming
asl.log=Destination=file;OnFirstLog=command,environment
BASEDIR=C:\app\apache\tomcat\7.0.4
BUILD_ID=2010-12-06_09-28-29
BUILD_NUMBER=8
BUILD_TAG=hudson-app-sso-8
BUILD_URL=http://localhost:8080/hudson/job/app-sso/8/
CATALINA_BASE=C:\app\apache\tomcat\7.0.4
CATALINA_HOME=C:\app\apache\tomcat\7.0.4
CATALINA_TMPDIR=C:\app\apache\tomcat\7.0.4\temp
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
ComSpec=C:\Windows\system32\cmd.exe
CURRENT_DIR=C:\app\apache\tomcat\7.0.4\bin
EXECUTABLE=C:\app\apache\tomcat\7.0.4\bin\catalina.bat
EXECUTOR_NUMBER=1
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\Chris Hane
HUDSON_COOKIE=aff0f818-7ab0-4c6a-b3d8-23809c79c923
HUDSON_HOME=C:\Users\Chris Hane\.hudson
HUDSON_SERVER_COOKIE=0a3f8a9a74717ace331d110709efc00b
HUDSON_URL=http://localhost:8080/hudson/
JAVA_ENDORSED_DIRS=C:\app\apache\tomcat\7.0.4\endorsed
JAVA_HOME=c:\Program Files\Java\jdk1.6.0_18
JAVA_OPTS= -Djava.util.logging.config.file="C:\app\apache\tomcat\7.0.4\conf\logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
JOB_NAME=app-sso
JOB_URL=http://localhost:8080/hudson/job/app-sso/
JRE_HOME=c:\Program Files\Java\jdk1.6.0_18
LOCALAPPDATA=C:\Users\Chris Hane\AppData\Local
LOGGING_CONFIG=-Djava.util.logging.config.file="C:\app\apache\tomcat\7.0.4\conf\logging.properties"
LOGGING_MANAGER=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
MAINCLASS=org.apache.catalina.startup.Bootstrap
NODE_LABELS=master
NUMBER_OF_PROCESSORS=8
OS=Windows_NT
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files\Java\jdk1.6.0_18\bin;c:\app\bin;C:\Program Files (x86)\Adobe\Adobe RoboHelp 7\RoboHTML;c:\app\apache\php-5.2.8-Win32\ext;C:\Program Files (x86)\QuickTime\QTSystem\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1a05
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
QTJAVA=C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip
SESSIONNAME=Console
SVN_REVISION=5353
SVN_URL=******
SystemDrive=C:
SystemRoot=C:\Windows
TEMP=C:\Users\CHRISH~1\AppData\Local\Temp
TITLE=Tomcat
TMP=C:\Users\CHRISH~1\AppData\Local\Temp
USERPROFILE=C:\Users\Chris Hane
windir=C:\Windows
WORKSPACE=C:\Users\Chris Hane\.hudson\jobs\app-sso\workspace
_EXECJAVA=start "Tomcat" "c:\Program Files\Java\jdk1.6.0_18\bin\java"
_RUNJAVA="c:\Program Files\Java\jdk1.6.0_18\bin\java"
_RUNJDB="c:\Program Files\Java\jdk1.6.0_18\bin\jdb"
Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
java.lang.ClassNotFoundException: org.apache.juli.ClassLoaderLogManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.util.logging.LogManager$1.run(LogManager.java:168)
at java.security.AccessController.doPrivileged(Native Method)

From this output, it looks like Hudson is launching Gradle with $JAVA_OPTS set, and asking Gradle to use org.apache.juli.ClassLoaderLogManager for logging. Which it cannot do.

Have you tried using version 1.4 of the Gradle Hudson plugin? I think there are fixes in that version to launch Gradle without $JAVA_OPTS.

Version 1.4 of the gradle plugin is the one I am using and hudson is at 1.387.

I see in the hudson gradle plugin where the JAVA_OPTS should be deleted. Wonder why it is not.

Anyway, I modified the gradle.bat file to unset JAVA_OPTS (set JAVA_OPTS=) and that takes care of this issue - at least as a workaround.

Do we know if this is a gradle or a jenkins issue? I'm seeing it in gradle 1.3 in Jenkins with Tomcat 7.

Jenkins ticket: https://issues.jenkins-ci.org/browse/JENKINS-7702

Seems like a Tomcat misconfiguration. Use 6.0.37+ or 7.0.38+, or just use setenv.sh to begin with. https://issues.apache.org/bugzilla/show_bug.cgi?id=54601

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

I do not think this was ever a bug in Gradle; it can be closed.