joda-time jar conflict issue in javacallout

[pmallikarjuna]

HI experts, i'm trying to use org.joda.time.DateTime in javacallout for SAML token generation but its throwing below error in cloud version. i tried including same version joda-time jar in my callout jar but couldn't help. 

Any suggestion? workarounds to get rid of this issue?

Error:

java.lang.LinkageError: loader constraint violation: when resolving interface method "org.opensaml.saml2.core.Response.setIssueInstant(Lorg/joda/time/DateTime;)V" the class loader (instance of com/apigee/messaging/resource/JavaResourceClassLoader) of the current class, com/apigee/callout/SAML2Assertion, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for the method's defining class, org/opensaml/saml2/core/StatusResponseType, have different Class objects for the type org/joda/time/DateTime used in the signature at com.apigee.callout.SAML2Assertion.buildSAMLResponse(SAML2Assertion.java:446) at

[sillan_dt]

You need to do proper packaging of jar. The path mismatch is happening. Please refer 

https://docs.apigee.com/api-platform/reference/policies/java-callout-policy#packaging 

[pmallikarjuna]

i have tried with joda-time jar and without jar but the issue is same. And also tried by adding all joda-time jar classes to my local jar but couldn't resolve the issue .

[API-Evangelist]

If it was on-prem it would have easy to look thru /lib/thirdparty  directory and resolve but since it is cloud would reach out to support as it would need to review. You want to exclude since it is conflicting..

back in days had close to similar issue

https://www.googlecloudcommunity.com/gc/Apigee/java-lang-LinkageError-loader-constraint-violation-wh...

[dchiesa1]

That is confounding. It seems that you have two different class loaders. This may lead to the "different class objects" problem you reported. See here for some details. 

...the class signature is composed of the class full qualified name and the classloader that loaded the class. If a class is loaded two times from two different classloaders (same hierarchy), there will be two different classes for the JVM. Trying to point a object reference of one class to a variable of the other will trhow a ClassCastException.

So maybe you need to remove jodatime from the list of jars in the proxy?

But that may not be a solution. 

It's a shame that opensaml depends on jodatime, and not on java.time. 

Faced with similar problems in the past, I have elected to implement the code myself, for doing signatures and so on. Eliminating the dependency on opensaml and wss4j and so on.  One example:  a callout for producing a SAML AuthnRequest.

What problem are you solving, btw?  There is a builtin policy for SAML Generation and another for SAML Verification. What do you need to do that isn't covered by those policies? 

[pmallikarjuna · Accepted solution]

Thank you, dchiesa1. i agree with your solution. the cloud version opnesmal jar is using different version of  joda-time datetime class. Finally my issue has been resolved after adding below dependent jars in the resource folder. 

joda-time-2.9.4.jar

opensaml-2.6.4.jar

openws-1.5.4.jar

xmltooling-1.4.4.jar