apache httpclient 4.x - Google Java API conflicted with ColdFusion CFHTTP?

Question

I tried copying all those JAR's found in the google-api-client-assembly-1.20.0-1.20.01.zip (downloaded from https://developers.google.com/api-client-library/java/google-api-java-client/download) to {cf_root}/lib, restart ColdFusion, and everything loaded up fine. However, when I used <cfhttp>:

org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [/] threw exception [org.apache.http.impl.client.DefaultHttpClient.setRedirectStrategy(Lorg/apache/http/client/RedirectStrategy;)V] with root cause
java.lang.NoSuchMethodError: org.apache.http.impl.client.DefaultHttpClient.setRedirectStrategy(Lorg/apache/http/client/RedirectStrategy;)V
    at coldfusion.tagext.net.HttpTag.createConnection(HttpTag.java:1728)
    at coldfusion.tagext.net.HttpTag.connHelper(HttpTag.java:928)
    at coldfusion.tagext.net.HttpTag.doEndTag(HttpTag.java:1219)

When I remove all of the google jars from {cf_root}/lib, it works as expected again. My workaround would be using the tokeninfo endpoint instead of com.google.api.client.googleapis.auth.oauth2.GoogleIdTokenVerifier, but Google recommends against it for production use.

The easiest way to validate an ID token is to use the tokeninfo endpoint. Calling this endpoint involves an additional network request that does most of the validation for you, but introduces some latency and the potential for network errors. For these reasons, it is suitable only for deployments with fewer than 100 monthly active users, as well as for debugging and informational purposes.

https://developers.google.com/identity/sign-in/ios/backend-auth

Any better solution to get around org.apache.http.impl.client.DefaultHttpClient being resolved to something else once the Jar's from google are loaded in ColdFusion?

Answer 1

(From comments)

Sounds like the jar that is conflicting is httpclient-4.0.1.jar. Removing it should resolve that specific error. However, it probably will not be the only conflict/error. A lot of the jars are pretty common, and could be used by CF as well, for example commons-logging-1.1.1.jar.

Since you are using CF10, have you tried loading the jars in your Application.cfc using the new feature this.javaSettings? It is basically a rip of Mark Mandel's JavaLoader.cfc. Just specify the paths of the jars you wish to load, or the directories to check for jars, ie

THIS.javaSettings = {LoadPaths = [".folder",".foldersomeLib.jar"] };

Obviously when using this feature, do not put the jars in {cf_root}lib, or anywhere else in the CF class path, as it defeats the purpose of dynamic class loading.