[JIRA] (JENKINS-57833) All builds with maven pipeline plugin fail with java.lang.AbstractMethodError while parsing event spy log

26 views
Skip to first unread message

markus.till@bosch-si.com (JIRA)

unread,
Jun 4, 2019, 3:24:02 AM6/4/19
to jenkinsc...@googlegroups.com
Markus Till updated an issue
 
Jenkins / Bug JENKINS-57833
All builds with maven pipeline plugin fail with java.lang.AbstractMethodError while parsing event spy log
Change By: Markus Till
Summary: All builds with maven pipeline plugin fail with java.lang.AbstractMethodError while parsing maven event spy log
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

cleclerc@cloudbees.com (JIRA)

unread,
Jun 4, 2019, 12:36:02 PM6/4/19
to jenkinsc...@googlegroups.com
Cyrille Le Clerc assigned an issue to Cyrille Le Clerc
Change By: Cyrille Le Clerc
Assignee: Alvaro Lobato Cyrille Le Clerc

cleclerc@cloudbees.com (JIRA)

unread,
Jun 4, 2019, 6:31:03 PM6/4/19
to jenkinsc...@googlegroups.com
Cyrille Le Clerc commented on Bug JENKINS-57833
 
Re: All builds with maven pipeline plugin fail with java.lang.AbstractMethodError while parsing event spy log

Can you please run the following groovy script in the Jenkins Script Console ("Manage Jenkins / Script Console") to understand from which jar the DocumentBuilderFactory was loaded?

import javax.xml.parsers.DocumentBuilderFactory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

println "DocumentBuilderFactory: " + dbf

Class klass = dbf.class

java.security.CodeSource codeSource = klass.getProtectionDomain().getCodeSource()
 
if (codeSource == null) {
  println(klass.toString() + " -> source not found")
} else {
  println(klass.toString() + " -> " + codeSource.getLocation());
}

Reference:

https://github.com/jenkinsci/pipeline-maven-plugin/blob/pipeline-maven-3.7.1/jenkins-plugin/src/main/java/org/jenkinsci/plugins/pipeline/maven/MavenSpyLogProcessor.java#L83

        DocumentBuilder documentBuilder;
        try {
            DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

            // https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md#jaxp-documentbuilderfactory-saxparserfactory-and-dom4j
            dbf.setExpandEntityReferences(false);
            dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); // <== CAUSING AbstractMethodError

cleclerc@cloudbees.com (JIRA)

unread,
Jun 4, 2019, 6:32:03 PM6/4/19
to jenkinsc...@googlegroups.com
Cyrille Le Clerc edited a comment on Bug JENKINS-57833


Can you please run the following groovy script in the Jenkins Script Console ("Manage Jenkins / Script Console") to understand from which jar the DocumentBuilderFactory was loaded?

{code}

import javax.xml.parsers.DocumentBuilderFactory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

println "DocumentBuilderFactory: " + dbf

Class klass = dbf.class

java.security.CodeSource codeSource = klass.getProtectionDomain().getCodeSource()

if (codeSource == null) {
  println(klass.toString() + " -> source not found")
} else {
  println(klass.toString() + " -> " + codeSource.getLocation());
}
{code}


 Sample output when things go right:

{noformat}
DocumentBuilderFactory: com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl@52728a9b
class com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl -> source not found
{noformat}

 Reference:

https://github.com/jenkinsci/pipeline-maven-plugin/blob/pipeline-maven-3.7.1/jenkins-plugin/src/main/java/org/jenkinsci/plugins/pipeline/maven/MavenSpyLogProcessor.java#L83
{code}

        DocumentBuilder documentBuilder;
        try {
            DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

            // https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md#jaxp-documentbuilderfactory-saxparserfactory-and-dom4j
            dbf.setExpandEntityReferences(false);
            dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); // <== CAUSING AbstractMethodError

{code}

markus.till@bosch-si.com (JIRA)

unread,
Jun 6, 2019, 9:26:02 AM6/6/19
to jenkinsc...@googlegroups.com

I get the following output. But why is "source not found" the expected behavoir? shouldn't there be a valid class loaded?

DocumentBuilderFactory: com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl@57dc5f4f
class com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl -> source not found

markus.till@bosch-si.com (JIRA)

unread,
Jun 6, 2019, 9:31:02 AM6/6/19
to jenkinsc...@googlegroups.com

I don't really get how to resolve this. Should I add -Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl to the starting Jenkins Process or to the maven run?

cleclerc@cloudbees.com (JIRA)

unread,
Jun 6, 2019, 9:57:01 AM6/6/19
to jenkinsc...@googlegroups.com

Which jvm version are you using?

markus.till@bosch-si.com (JIRA)

unread,
Jun 6, 2019, 10:59:02 AM6/6/19
to jenkinsc...@googlegroups.com

seems adding the -Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl  to the JAVA_OPTS seem to work. But I'm still confused why this is needed. 

markus.till@bosch-si.com (JIRA)

unread,
Jun 6, 2019, 11:00:01 AM6/6/19
to jenkinsc...@googlegroups.com

the one bundeld with the offical docker image 

markus.till@bosch-si.com (JIRA)

unread,
Jun 6, 2019, 11:01:02 AM6/6/19
to jenkinsc...@googlegroups.com
Markus Till edited a comment on Bug JENKINS-57833
the one bundeld with the offical docker image 



openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)

cleclerc@cloudbees.com (JIRA)

unread,
Jun 6, 2019, 11:08:02 AM6/6/19
to jenkinsc...@googlegroups.com

> But why is "source not found" the expected behavoir? shouldn't there be a valid class loaded?

"source not found" means that it is provided by the JVM jar(s) directly and this is what we desire. Sometimes, it's an old/outdated XML parsing implementation that it loaded and you get a source such as ".../xercesImpl-2.6.2.jar". It is often caused by plugins forgetting to exclude old versions of Xerces from their dependencies.

class org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -> file:/var/jenkins_home/plugins/registry_reporter/WEB-INF/lib/xercesImpl-2.6.2.jar

https://issues.jenkins-ci.org/browse/JENKINS-47486?focusedCommentId=318000&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-318000

cleclerc@cloudbees.com (JIRA)

unread,
Jun 6, 2019, 11:09:02 AM6/6/19
to jenkinsc...@googlegroups.com
Cyrille Le Clerc edited a comment on Bug JENKINS-57833
> But why is "source not found" the expected behavoir? shouldn't there be a valid class loaded?

"source not found" means that it is provided by the JVM jar(s) directly and this is what we desire. Sometimes, it's an old/outdated XML parsing implementation that it loaded and you get a source such as ".../xercesImpl-2.6.2.jar". It is often caused by plugins forgetting to exclude old versions of Xerces from their dependencies.
> openjdk version "1.8.0_212"

This is a JDK that works well. The problem is likely to be a plugin that pull an outdated version of XercesImpl

 {noformat}

class org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -> file:/var/jenkins_home/plugins/registry_reporter/WEB-INF/lib/xercesImpl-2.6.2.jar

cleclerc@cloudbees.com (JIRA)

unread,
Jun 11, 2019, 12:11:02 PM6/11/19
to jenkinsc...@googlegroups.com

Markus Till can you please search for any xerces jar file in the plugins that you have loaded in your instance. It is typically outdated versions of xerces that cause issues with the DocumentBuilderFactory. Can you on the master run "find -iname "xerces"" under "JENKINS_HOME/plugins".

It looks like

$ cd <JENKINS_HOME>/plugins
# verify that we are in the right folder verifying the number of jar files we found
$ find -iname "*.jar" | wc -
$ find -iname "*xerces*.jar"

Result typically looks like:

$ find -iname "*.jar" | wc -l
1262
$ find -iname "xerces*.jar"
./analysis-core/WEB-INF/lib/xercesImpl-2.11.0.jar
$

martin.doenicke@tracetronic.de (JIRA)

unread,
Jun 12, 2019, 8:47:02 AM6/12/19
to jenkinsc...@googlegroups.com

We had the same issue after updating the the pipeline-maven-plugin

find -iname "xerces*.jar"
./plugins/analysis-core/WEB-INF/lib/xercesImpl-2.11.0.jar
./plugins/emma/WEB-INF/lib/xercesImpl-2.9.1.jar
./plugins/jdepend/WEB-INF/lib/xercesImpl-2.11.0.jar
./plugins/build-pipeline-plugin/WEB-INF/lib/xercesImpl-2.9.1.jar
./plugins/discard-old-build/WEB-INF/lib/xercesImpl-2.6.2.jar

Removing the plugin discard-old-build (since we didn't use it anyway) has solved the issue on our side.

vincent.letarouilly@gmail.com (JIRA)

unread,
Jul 18, 2019, 4:08:03 AM7/18/19
to jenkinsc...@googlegroups.com

Martin Dönicke Thanks, that did the trick for us too !

cleclerc@cloudbees.com (JIRA)

unread,
Jul 18, 2019, 9:14:02 AM7/18/19
to jenkinsc...@googlegroups.com
Cyrille Le Clerc closed an issue as Fixed
 

Closing the issue. The issue is to identify the outdated "xerces jar file" brought by another plugin.
Change By: Cyrille Le Clerc
Status: Open Closed
Resolution: Fixed
Reply all
Reply to author
Forward
0 new messages