2

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?

Leigh
  • 28,765
  • 10
  • 55
  • 103
Henry
  • 32,689
  • 19
  • 120
  • 221
  • Not sure about your overall goal, but do you really need *all* of those jars? Also we need more details A) Which `/lib` directory - {cf_root}\lib? B) Exactly which jar(s) did you remove? Sounds like the one that is conflicting is `httpclient-4.0.1.jar`. Removing it should resolve that *specific* error – Leigh Aug 14 '15 at 02:33
  • C) Since you are using CF10, have you tried loading the jars in your [application.cfc](http://help.adobe.com/en_US/ColdFusion/10.0/Developing/WSe61e35da8d318518-106e125d1353e804331-7ffe.html) using `this.javaSettings`? (Obviously if you do that, 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). – Leigh Aug 14 '15 at 02:33
  • *B) Exactly which jar(s) did you remove?* If you mean you removed httpclient-4.0.1.jar already, what is the issue? If you placed all of the jars in the CF class path, using the google library should automatically pick up whatever version of the jar is bundled with CF. So again, it is not clear what problem you are having when the jar is removed. Can you elaborate? – Leigh Aug 14 '15 at 03:37
  • It's not clear to me which jar is required, therefore I have copied all the jar's in the zip to `/lib`. – Henry Aug 14 '15 at 04:41
  • A.) {cf_root}/lib, yes. B.) all of the jar's from the zip, I will try removing httpclient*.jar tomorrow and see. – Henry Aug 14 '15 at 04:42
  • 1
    (Edit) 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`. You probably do not need all of the jars, but it depends on what you are doing. See if they have a dependency list. If not, you could probably deduce it from the [maven setup](https://developers.google.com/api-client-library/java/google-api-java-client/setup#maven). Also, for grins try [option "C)"](http://stackoverflow.com/questions/32001030/google-java-api-conflicted-with-coldfusion-cfhttp#comment51906002_32001030) – Leigh Aug 14 '15 at 14:23
  • @Leigh wow, using CF10's `this.javaSettings` actually works! Please post as an answer and I'll mark it as the correct answer, thanks! – Henry Aug 14 '15 at 18:27
  • 1
    Cool, I was not sure. Glad it worked, because some libraries have issues (like old versions of dom4j) that you cannot easily fix, even *with* a dynamic class loader. Java's version of DLL Hell ;-) – Leigh Aug 14 '15 at 18:36

1 Answers1

2

(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\",".\folder\someLib.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.

Leigh
  • 28,765
  • 10
  • 55
  • 103
  • You are welcome. FWIW, the reason it did not work before is that essentially class loaders can only load a single version of a particular library at a time. When you place multiple versions of the *same* library in the CF class path (ie Apache HTTPClient library: httpclient-3.1.2.jar and httpclient-4.0.1.jar) the core CF class loader will only load one of them. If that version it loads is incompatible with whatever code you are executing (ie cfhttp) it causes an error. – Leigh Aug 14 '15 at 20:23
  • 1
    Using `this.javaSettings`, lets you keep everything separate by creating a totally separate class loader from the one used for regular CF code. Allowing CF to use whatever jar versions it needs (from its class path) and your application to use different versions of the same jars by creating its own class path, ie the directories/jars you specify in `LoadPaths` – Leigh Aug 14 '15 at 20:25