序言; 我对 Workday Studio 不熟悉,而且似乎没有任何公共文档,所以这个答案可能存在一些细微差别。
概括
Workday,您的代码或可能正在使用的某些库正在引用不存在或找不到的 bean(请参阅 Spring 文档:核心技术)。
如果您在这里没有编写任何 Java 代码,那几乎可以肯定是 Workday Studio 中的配置问题或错误。以下是基于您提供的信息的一些观察。但首先,一个疯狂的猜测。
胡乱猜测
Workday 的处理方式似乎与 cURL 或 SoapUI 略有不同。cURL 和 SoapUI 正在执行以下操作:
- 使用参数向 URL 发送 GET 请求,并在标头中包含 API 密钥
- 服务器发送所需的响应
但是,听起来 Workday 正在做的事情更像是:
- 发送 GET 请求,假设预授权场景,使用挑战类型:'token'
- 服务器使用其框架(可能是 Rails)用于令牌的正确身份验证类型进行响应;'http-token-auth'
- Workday(错误地)假设服务器正在使用 Spring 框架,并尝试根据该响应加载正确的 auth-type bean
- Spring 框架 barfs,因为没有这样的 bean
我想有一些方法可以让 Workday 与标准 REST API 很好地配合使用,并且只需按照预期将 API 密钥提供给供应商的服务器,而不是尝试进行挑战/响应。
如果不是这样,下面还有一些杂草的可能性。
奇怪的 Bean 名称
错误中指定的 bean 名称是http-token-auth
,在 kebab-case 中。命名 bean 的约定是(较低的)camelCase,因此无论在哪里指定,都可能只是使用了错误的大小写。
这可能在 Workday Studio 配置、XML 配置文件或您编写的一些自定义代码中(如果有)。
配置
如果 bean 名称正确,则可能存在其他配置问题。Spring 可以通过扫描类路径(参见 Spring 文档:类路径扫描和托管组件)或从项目 XML 加载它来隐式检测候选组件。问题可能是:
- 构建路径错误(如果您不熟悉,请参阅esaj 的这个答案)
- 类路径是错误的,所以 Spring 只是看不到它。在这种情况下,这似乎是特定于工作日的配置。
- 该 bean 在项目 XML 中,但是是嵌套的。在这种情况下,它只能被封闭的 bean 访问。对此的一种解决方案是激活相应的配置文件。
- 包装问题;如果 bean 未包含在生成的已部署 jar 中,则会出现问题。dawrutowicz 的这个解决方案应该适用于许多情况。
- 项目配置;您的屏幕截图中的所有设置看起来都完全正确并且应该可以正常工作,因此您的项目设置中可能隐藏了一些东西
Workday Studio 中的错误
这似乎不太可能,但总是有可能的。如果您还没有编写任何 Java 代码,那么 Workday 代码中的某些东西正在提供这个意外的“http-token-auth”,或者不恰当地从其他地方接受它并尝试使用它加载一个 bean。
最后的想法
由于您正在尝试使用供应商的 API,我强烈建议您尝试与那里的一位工程师合作。保证,他们至少有一名工程师以前处理过复杂的集成问题。他们将提供有关其 API 的更多详细信息,并且可能能够就您能够共享的任何配置/代码为您提供更直接的输入。