Jenkins not creating build.xml in jobs after upgrading to JDK 17

Using Jenkins Ask a question
1

Jenkins setup:
Jenkins 2.462.2 (LTS)
Apache Tomcat 9.0.89 on Windows Server 2016
Oracle JDK 17.0.12

We’ve upgraded our Jenkins controller to 2.462.2 running on Tomcat on Windows. In the process, we’ve upgraded all plugins to recent versions. All seems fine with upgrade. We also later tried switching from Java JDK 11 to JDK 17. All booted fine, everything seems to work, but I noticed that when I ran a few jobs and restarted, the history doesn’t show the new jobs. When I investigate, I notice that there are no build.xml files in the builds folder under the job. If I run new jobs, the history shows the new job using a newer build number, but if I reload from disk that history goes away. When I switched back to JDK 11, the job does create the build.xml file and the history of the jobs run with JDK 11 stay in the history.

Tried running jobs under JDK 11 which were successful using the same plugins. Nothing is obvious in the logs. Several plugins were recently updated, but no configuration was changed from old versions running on JDK 11 to the new versions on JDK 11 then on JDK 17.

Here’s a snip from log:

SEVERE [Executor #1 for WinAgent1 : executing Run_Checkmarx #19] hudson.model.Run.execute Failed to save build record
              java.io.IOException: java.lang.RuntimeException: Failed to serialize hudson.model.AbstractBuild#culprits for class hudson.model.FreeStyleBuild
                             at hudson.XmlFile.write(XmlFile.java:223)
                             at hudson.model.Run.save(Run.java:2061)
                             at hudson.model.Run.execute(Run.java:1947)
                             at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
                             at hudson.model.ResourceController.execute(ResourceController.java:101)
                             at hudson.model.Executor.run(Executor.java:446)
              Caused by: java.lang.RuntimeException: Failed to serialize hudson.model.AbstractBuild#culprits for class hudson.model.FreeStyleBuild
                             at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:274)
                             at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:241)
                             at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:174)
                             at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:226)
                             at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:163)
                             at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68)
                             at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:59)
                             at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:44)
                             at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:83)
                             at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
                             at com.thoughtworks.xstream.XStream.marshal(XStream.java:1303)
                             at com.thoughtworks.xstream.XStream.marshal(XStream.java:1292)
                             at com.thoughtworks.xstream.XStream.toXML(XStream.java:1265)
                             at hudson.XmlFile.write(XmlFile.java:216)
                             ... 5 more
              Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private static final long java.util.Collections$UnmodifiableCollection.serialVersionUID accessible: module java.base does not "opens java.util" to unnamed module @3ad497c4
                             at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
                             at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
                             at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)

Also, note this is on Windows. I added the env variable JDK_JAVA_OPTIONS with the values “-add-opens java.base/java.land=ALL-UNNAMED -add-opens java.base/java.util=ALL-UNNAMED” hoping that that would provide the Java opts necessary. Though it seems that is picked up when I run java -version, the error persists when running a job.

Is there anything that needs to be configured after moving to JDK 17? I’m definitely missing something, but I’m desperate to solve this with JDK 11 support being dropped. I appreciate any help and can post a list of plugins, etc. if needed.

2

Are you sure the JDK_JAVA_OPTIONS are properly applied? As you run on tomcat the defaults that are set in the jenkins.war are not taken into account.
You should check with Process Explorer whether the java options are set.

3

Thanks Markus. To be honest I’m not sure they are applied correctly. There is so much on the Internet about JDK options but nothing that definitively says how to configure for Jenkins/Tomcat that I’ve been able to find. Any suggestions are appreciated, but I’ll check process explorer and keep looking for that instruction.

4

You might consider switching away from tomcat as the Jenkins project is not actively testing that everything works fine with tomcat. Only running Jenkins via the built-in jetty server is verified.
Other than that, look in the catalina.bat script, that is used to start tomcat. There it is explained that you should create a setenv.bat in CATALINA_BASE\bin where you can set e.g. CATALINA_OPTS , JDK_JAVA_OPTIONS seems to be not used although defined in the script

5

I figured this out. As we are running Tomcat on Windows as a service, we need to use the Tomcat9w.exe tool to manage JDK Options. This is mentioned within the catalina.bat file (which I finally read!) as it mentions that other methods such as setenv.bat and other local customizations have no effect.

In the tool, there is a Java tab where I add my --add-opens statements, which I was able to do. I added those in the format:
–add-opens=java.lang=ALL-UNNAMED
–add-opens=java.util=ALL-UNNAMED

(this is also were to add the:
“-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true” type of options as well.)

Once I made the change and saved, I restarted the service and confirmed the log shows the parameters loading and my problem is now solved. All jobs are creating build.xml files without error using JDK17.

I hate answering my own questions, but I had to find the specific solution for our specific requirement, but there were many pointers along the way that helped. Hopefully, this will help the next person experiencing something similar.

2 Likes