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

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

问题描述

我尝试复制在 google-api-client-assembly-1.20.0-1.20.01.zip(从 https://developers.google.com/api-client-library/java/google-api-java-client/download) 到 {cf_root}/lib,重启 ColdFusion,一切都加载好了.但是,当我使用 时:

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)

当我从 {cf_root}/lib 中删除所有 google jar 时,它再次按预期工作.我的解决方法是使用 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-在/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?它基本上是对 Mark Mandel 的 JavaLoader.cfc.只需指定要加载的 jar 的路径,或者要检查 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"] };

显然,在使用此功能时,不要将 jars 放在 {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天全站免登陆