I've written an Appian smart service plugin for an integration that has a de

If you're calling the classes from within the plug-in you wrote, can you leave out the jersey jars, since the classes you need are already in the atlassian jar?

Tried leaving out the Jersey jars, but then I get this exception: java.lang.NoSuchMethodError: com.sun.jersey.api.client.ClientResponse.getStatusInfo()Ljavax/ws/rs/core/Response$StatusType;
So doesn't look like I can leave out the Jersey jars. Any other thoughts on how I can resolve the class conflict while having both the Jersey and Atlassian jars present?

The best option is to try and find a way to just have the class in one jar. When you get the no such method error, have you specified where you're importing the method from?

If you really do need to have both jars present, there are three generally accepted methods of resolving this issue in java. However, fair warning, they're all pretty ugly.

1) Serialize and deserialize the object
2) Create a classloader that is the parent for both classes
3) Reflection

Thanks Eliot. We are trying to integrate with DocuSign using an Appian smart service plugin. The error is thrown when making a DocuSign method call such as when creating an envelope. The jersey jar is in turn a dependency for the docusign jar, which is why we need classes from the Jersey jar to load. However, classes with same name and package as Jersey jar are loaded from the Atlassian-rest jar in Appian thus causing the class conflict. We can't do away with the Jersey jar since DocuSign requires it, and it is unlikely we can do away with atlassian-rest jar since it comes prepackaged with Appian.
For those who have integrated with DocuSign before, did you run into a similar issue? How did you achieve the integration?

Hi gauravg568,

How are you integrating with DocuSign? Are you calling the DocuSign web service? If so, you might be able to get around this problem by generating your web service proxy classes using a different stack. For example, if you are using axis2, you can try with axis1.3 instead (the older version of axis works just fine but has only a few dependent jar files).

We are facing same issue with other OpenLPR API as well.. OpenLPR API uses jersey API for making rest calls. Here is the error..

Caused by: com.sun.jersey.spi.service.ServiceConfigurationError: com.sun.jersey.spi.HeaderDelegateProvider: The class com.sun.jersey.core.impl.provider.header.LocaleProvider implementing provider interface com.sun.jersey.spi.HeaderDelegateProvider could not be instantiated: Cannot cast com.sun.jersey.core.impl.provider.header.LocaleProvider to com.sun.jersey.spi.HeaderDelegateProvider..

Even I tried to overcome by changing class loader in class where issue occured, but it does not resolve the problem
ClassLoader old = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());

Jersey stuff...

Thread.currentThread().setContextClassLoader(old);