Bug 1299674 - xmlpull.jar causes java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service"
xmlpull.jar causes java.lang.LinkageError: loader constraint violation: when ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: groovy (Show other bugs)
23
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Michal Srb
Fedora Extras Quality Assurance
:
Depends On: 1299774
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-18 19:10 EST by Richard Chan
Modified: 2016-02-29 17:22 EST (History)
3 users (show)

See Also:
Fixed In Version: groovy-2.4.4-3.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-29 17:22:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 500909 None None None 2016-01-18 22:14 EST

  None (edit)
Description Richard Chan 2016-01-18 19:10:08 EST
Description of problem:
Running a SOAP client QName is loaded from xmlpull.jar and JVM rt.jar leading to 

Caught: java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current class, org/ejbca/core/protocol/ws/client/gen/EjbcaWSService, and the class loader (instance of <bootloader>) for the method's defining class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature
java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current class, org/ejbca/core/protocol/ws/client/gen/EjbcaWSService, and the class loader (instance of <bootloader>) for the method's defining class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature
	at org.ejbca.core.protocol.ws.client.gen.EjbcaWSService.<init>(EjbcaWSService.java:37)
	at com.example.ejbca.version.run(version.groovy:73)

Version-Release number of selected component (if applicable):
2.4.4

How reproducible:
Always

Steps to Reproduce:
1. Run groovy script using EJBCA SOAP service

Name qname = new QName("http://ws.protocol.core.ejbca.org/", "EjbcaWSService")
def ejbcasvc = new EjbcaWSService(new URL("https://example.com/ejbca/ejbcaws/ejbcaws?wsdl"), qname)
def ejbcaws = ejbcasvc.getEjbcaWSPort()
logger.info("Connected to EJBCA version: " + Ejbca.getVersion(ejbcaws))
2. The SOAP service is from 
https://www.ejbca.org/
3.

Actual results:
Caught: java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current class, org/ejbca/core/protocol/ws/client/gen/EjbcaWSService, and the class loader (instance of <bootloader>) for the method's defining class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature
java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current class, org/ejbca/core/protocol/ws/client/gen/EjbcaWSService, and the class loader (instance of <bootloader>) for the method's defining class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature
	at org.ejbca.core.protocol.ws.client.gen.EjbcaWSService.<init>(EjbcaWSService.java:37)


Expected results:
[main] INFO ejbca - Connected to EJBCA version: EJBCA 6.3.1.1 Community (r21429)


Additional info:
Upstream groovy-2.4.5 has xmlpull-1.1.3.1.jar. Not sure why that works but Fedora groovy doesn't.

Fedora 2.4.4: (with -verbose)
[Loaded javax.xml.namespace.QName from file:/usr/share/groovy/lib/xmlpull.jar]
[Loaded javax.xml.namespace.QName from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64/jre/lib/rt.jar]
Caught: java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current class, org/ejbca/core/protocol/ws/client/gen/EjbcaWSService, and the class loader (instance of <bootloader>) for the method's defining class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature


Upstream 2.4.5: (-verbose)
[Loaded javax.xml.namespace.QName from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64/jre/lib/rt.jar]
[Loaded javax.xml.namespace.QName$1 from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64/jre/lib/rt.jar]

Why upstream doesn't pull in its own  groovy-2.4.5/lib/pull-1.1.3.1.jar and have the same error?
Comment 1 Richard Chan 2016-01-18 19:12:35 EST
Can reproduce the error on RHEL 7. groovy 1.8
Comment 2 Richard Chan 2016-01-18 19:19:12 EST
Same issue if I set JAVA_HOME to Oracle JDK.
The issue may be the Fedora wrapper scripts.

With Oracle JDK:
[Loaded javax.xml.namespace.QName from file:/usr/share/groovy/lib/xmlpull.jar]
[Loaded javax.xml.namespace.QName from /opt/java/jdk1.8.0_60/jre/lib/rt.jar]
Caught: java.lang.LinkageError: loader constraint violation:
Comment 3 Richard Chan 2016-01-18 19:33:33 EST
A "hotfix" is to remove the link from /usr/share/groovy/xmlpull.jar to /usr/share/java/xpp3.jar OR link it to upstream's groovy-2.4.5/lib/xmlpull-1.1.3.1.jar.

I have verified that this works.

Maybe a bug in xpp3? It should not bundle javax/xml/namespace/QName.class
Comment 4 Richard Chan 2016-01-18 19:43:03 EST
This may actually be a bug in xpp3.jar (not sure why it bundles QName). I have filed 1299679.
Comment 5 Richard Chan 2016-01-18 22:04:38 EST
Not a bug in xpp3 either: maybe groovy should link to xpp3_min 

/usr/share/groovy/xmlpull.jar -> /usr/share/java/xpp3_min.jar instead of 
/usr/share/java/xpp3.jar.

This is what upstream seems to do: its xmlpull.jar looks more like xpp3_min.jar instead of xpp3.jar.
Comment 6 Richard Chan 2016-01-18 22:07:18 EST
On Fedora should be xpp3-minimal.jar

ln -fs /usr/share/java/xpp3-minimal.jar /usr/share/groovy/xmlpull.jar
Comment 7 Michal Srb 2016-02-19 03:29:01 EST
Thanks for the bug report Richard, and thanks for your analysis of the problem. You're right, the symlink should point to "minimal" version of the xpp3 library.
Comment 8 Fedora Update System 2016-02-19 06:20:34 EST
groovy-2.4.4-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d814445cea
Comment 9 Fedora Update System 2016-02-21 12:59:13 EST
groovy-2.4.4-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d814445cea
Comment 10 Fedora Update System 2016-02-29 17:22:35 EST
groovy-2.4.4-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.