Google Java API与ColdFusion CFHTTP冲突? [英] Google Java API conflicted with ColdFusion CFHTTP?

查看:357
本文介绍了Google Java API与ColdFusion CFHTTP冲突?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我尝试复制在 google-api-client-assembly-1.20.0-1.20.01.zip 中找到的所有JAR文件(从 https://developers.google.com/api-client-library/ java / google-api-java-client / download )到 {cf_root} / lib ,重新启动ColdFusion,但是,当我使用< cfhttp>

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)

当我删除所有的google jar {cf_root} / lib ,它会再次正常工作。我的解决方法是使用tokeninfo端点而不是 com.google.api.client.googleapis.auth.oauth2.GoogleIdTokenVerifier ,但Google建议不要使用它。

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.


验证ID令牌的最简单方法是使用tokeninfo
端点。调用此端点涉及额外的网络请求
执行大多数验证,但引入一些延迟
和潜在的网络错误。由于这些原因,
仅适用于每月活动
用户少于100个的部署,以及调试和信息用途。

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

任何更好的解决方案 org.apache.http.impl .client.DefaultHttpClient 在ColdFusion中加载了来自google的Jar之后被解析为别的东西?

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?

推荐答案

(从注释)

听起来像冲突的jar是 httpclient-4.0.1.jar 。删除应该会解决具体错误。但是,它可能不会是唯一的冲突/错误。很多jar是很常见的,也可以被CF使用,例如 commons-logging-1.1.1.jar

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.

由于您使用的是CF10,因此您尝试使用新功能加载Application.cfc中的jars。 this.javaSettings ?它基本上是马克·曼德尔的的撕裂 JavaLoader.cfc 。只需指定您要加载的jars的路径,或者检查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]};

显然,当使用此功能时,不要将瓶子放在 {cf_root} \lib CF类路径,因为它违反了动态类加载的目的。

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.

这篇关于Google Java API与ColdFusion CFHTTP冲突?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆